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PREFACE 
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1.  INTRODUCTION 


The  increasing  complexity  of  the  modem  helicopter  has  often  resulted  in  unacceptably  high 
maintenance  hours  and  ground  and  flight  time  to  isolate  mechanical  and  flight  control  component 
faults.  Often  this  is  due  to  a  lack  of  expertise  in  troubleshooting  techniques  or  simply  to  inadequate 
tools  and  techniques.  This  lack  of  expertise  often  results  in  a  “shotgun”  approach  to  maintenance 
with  removal  of  good  parts  and  subsequently  high  “retest  OK”  rates.  Sometimes,inability  to  bring 
aircraft  vibrations  to  acceptable  levels  can  even  result  in  restrictions  in  the  operating  envelope  for 
the  affected  aircraft.  Sikorsky  field  experience  has  borne  this  out  In  visits  to  military 
installations,  Sikorsky  aeromechanics  engineers  found  that  aircraft  surveyed  were  often  outside 
specification  limits  in  vibration  levels.  The  application  of  proper  track  and  balance  procedures 
returned  the  aircraft  to  within  limits.  All  of  this  points  to  the  need  for  improved  equipment  and 
enhanced  procedures. 

The  objective  of  the  Mechanical  Component  Diagnostic  System  (MCDS)  program  was  to  capitalize 
on  the  recent  advances  and  developments  in  the  field  of  artificial  intelligence,  onboard  data 
recording/processing,  and  rotor  tuning  equipment  to  develop  a  system  with  the  capability  to 
perform  the  following: 

1.  An  on-aircraft  pilot  or  copilot  operated  rotor  vibration  diagnostic  system  that  will 
determine,  in  flight,  the  corrections  needed  to  improve  main  and  tail  rotor  track  and 
balance  and  reduce  one-per-rev  vibration  of  both  rotors. 

2.  An  aircraft  vibration  troubleshooting  concept  which  will  monitor,  distinguish  and  process 
vibrations  which  are  rotor  induced,  rotating  shaft  induced,  or  result  from  control  system 
feedback  or  loose  mounts. 

3.  A  flight  control  subsystem  troubleshooting  concept 

The  MCDS  design  process  built  upon  prior  research  performed  during  an  earlier  Army-contracted 
R&D  program  called  the  UH-60  Advanced  Maintenance  Demonstration,  as  well  as  an  Army  and 
Navy  sponsored  Structural  Usage  Monitor  (SUM)  program.  The  main  contribution  of  these 
programs  was  the  development  of  practical  rotorcraft  regime  recognition  algorithms  which  allowed 
the  automation  of  vibration  data  gathering  without  the  need  for  pilot  participation.  The  flight  data 
recorder  used  in  the  MCDS  was  also  derived  from  the  SUM  program. 

The  MCDS  concept  integrates  a  vibration  analyzer,  flight  data  recorder  and  cockpit  display.  This 
concept  provides  automated  background  monitoring  with  minimum  pilot  interaction  required.  The 
system  processes  the  data  onboard  with  little  requirement  for  extensive  ground-based 
postprocessing.  The  calculated  corrections  for  smoothing  one-per-rev  rotor  induced  vibrations  are 
available  inflight.  In  addition,  detection  and  capture  of  other  aircraft  vibrations  and  vibration 
detectable  problems  is  completed  while  airborne,  and  advice  is  given  for  further  ground-based 
diagnosis  and  repair.  A  concept  for  detection  and  capture  of  certain  flight  control  component 
problems  was  also  developed. 

A  bench  test  of  the  MCDS  configured  for  the  UH-60A  was  performed  and  demonstrated  the 
following  capabilities:  automatic  data  acquisition  and  analysis  based  on  aircraft  state  (regime);  pilot 
initiated  capture  of  vibration  and  aircraft  data  (for  later  analysis);  in-flight  system  status  on  pilot 
request;  and  vibration  data  trending  and  archiving.  Mechanical  subsystems  monitored  include:  main 
and  tail  rotor  (calculation  of  smoothing  adjustments),  engine  high  speed  shafts,  oil  cooler,  tail  drive 
shaft  bearing  temperature,  and  general  airframe  vibration  levels. 
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The  following  section  provides  a  description  of  how  MCDS  capabilities  provide  technological 
advances  over  existing  UH-60A  field  maintenance  procedures.  Also  included  is  an  overview  of 
the  MCDS  operational  modes  and  a  walk-through  of  a  typical  flight  with  MCDS. 
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This  section  reviews  the  capabilities  of  MCDS  from  a  diagnostic  viewpoint  as  well  as  describes  the 
MCDS  user  interface  through  a  description  of  modes  of  operation  and  a  walk-through  of  a  typical 
flight  with  MCDS. 

2.1.  DIAGNOSTIC  CAPABILITIES 


This  section  provides  a  summary  of  the  diagnostic  capabilities  for  each  fault  mode  covered  by 
MCDS  and  some  potential  enhancements  that  should  be  considered  in  any  future  system  updates. 
(Note  that  references  to  “Sikorsky”  within  this  section  are  to  the  aeromechanics  engineers  who 
support  the  production  line  and  develop  vibration  diagnostics.)  MCDS  capabilities  are  compared 
with  present  UH-60  diagnostic/troubleshooting  procedures  in  Table  1. 


TABLE  1 .  COMPARISON  OF  MCDS  DIAGNOSTICS  CAPABILITIES 

WITH  CURRENT  CAPABILITIES  ON  THE  UH-60A 


Diagnostic  Task  Present  Operational 

Capability 

MCDS 

Capability 

Detection  /  Isolation 

1 P  Vibrations: 

Main  Rotor  Track  and  Balance: 

Flat  Pitch  Track  (PCR  Adjustments) 

Note  1 

Onboard 

Ground  Balance  (Hub  Wt.  Adjustments) 

Note  1 

Onboard 

Hover  Spread  (Tip  Wt.  Distribution) 

None 

Onboard  /  Ground 

1  High  Speed  Vibration:  1 

PCR  Adjustments 

Note  1 

Onboard 

Tab  Adjustments 

None 

Onboard 

Blade  Resequence 

None 

Onboard 

Dampers 

None 

Onboard  /  Ground 

Tail  Rotor  Balance 

Note  1 

Onboard 

4P  Vibrations: 

Nose  Absorber 

Note  1 

Onboard 

Cabin  Absorber 

Note  1 

Onboard 

Shafts: 

Engine  Drive 

Note  1 

Onboard  /  Ground 

Oil  Cooler 

Note  1 

Onboard  /  Ground 

Tail  Rotor  Drive 

Balance 

None 

Onboard  /  Ground 

Bearings 

None 

Onboard  /  Ground 

Disconnect 

None 

Onboard 

General  Vibrations 

None 

Onboard  /  Ground 

Stabilator 

Note  2 

Onboard  /  Ground 

Note  1.  Requires  aircraft  instrumentation,  dedicated  flight 

and  use  of  maintenance  manuals. 

Note  2.  Requires  detailed  fault  tree  analysis. 

Existing  procedures  in  track  and  balance  are  essentially  similar  for  all  helicopter  models.  They 
require  instrumenting  the  aircraft  and  making  measurements  at  several  locations  under  various 
flight  conditions  and  using  a  hand-held  strobe  light  to  measure  blade  track.  Analysis  of  the  data  is 
done  by  manually  plotting  the  measured  data  on  graphic  plots  and  inteipreting  these  plots  to 
determine  an  adjustment.  Implemented  correctly,  these  adjustments  are  usually  in  the  correct 
direction;  however,  they  are  not  optimum  and  may  require  several  flights  to  finally  bring  the 
aircraft  within  specifications.  A  review  of  unpublished  procedures  used  at  Sikorsky  by 
aeromechanics  experts  shows  that  more  automated  tools  are  used  and  additional  procedures  are 
available  for  rotor  diagnostics  and  smoothing.  There  are  several  basic  tasks  pertaining  to  rotor 
smoothing  which  were  examined  by  the  MCDS  program  and  are  summarized  below: 

•  Flat  pitch  track  -  The  rotor  is  initially  tracked  at  flat  pitch  if  one  or  more  new  blades  are 
installed  or  other  major  rotor  hub  changes  are  made.  Current  practice,  using  the  strobe 
with  mounted  blade  targets,  at  best  achieves  1/4”  accuracy.  MCDS  and  Sikorsky,  using 
an  automatic  track  sensor,  achieves  an  accuracy  of  only  a  few  millimeters  with  very  good 
repeatability.  In  addition,  MCDS  can  tailor  its  adjustment  strategy  based  on  inputs  of  what 
rotor  maintenance  was  completed. 

•  Ground  balance  -  Rotor  balance  data  is  acquired  using  the  main  rotor  contactor  and 
accelerometers.  Although  data  is  acquired  in  the  same  manner  by  the  field,  MCDS  and 
Sikorsky,  MCDS  has  the  added  capability  to  output  this  adjustment  as  a  revised  weight 
configuration  (if  the  existing  configuration  is  maintained  by  input  of  all  changes  to  the 
MCDS). 

•  Hover  spread  -  This  is  a  change  in  blade  track  spread  when  the  aircraft  changes  from  flat 
pitch  ground  to  hover  condition  and  indicates  a  possible  blade  problem  (probably  due  to 
tip  weight  distribution  problems).  There  is  currently  no  accurate  field  procedure  to  check 
for  this.  MCDS  will  check  this  and  indicate  the  problem.  Further  development  work  in 
flight  testing  may  allow  MCDS  to  automatically  calculate  tip  weight  adjustments  in 
addition  to  indicating  the  problem. 

•  High  speed  track  and  balance  -  This  currently  involves  taking  track  and  vibration  data  at 
various  test  regimes,  plotting  the  data,  and  manually  determining  an  adjustment  to  Pitch 
Control  Rods  (PCR).  MCDS  and  Sikorsky  automatically  acquire  this  data  and  output 
optimum  adjustments  for  both  vertical  and  roll  vibration  while  also  minimizing  track 
spread.  These  adjustments  include  bending  the  blade  tab  which  is  not  currently 
implemented  by  the  Army  in  the  field.  MCDS  could  additionally  provide  alternate 
maintenance  actions  with  an  indication  of  the  chances  of  success  of  each  maintenance 
option  to  bring  the  aircraft  into  specification.  Typical  maintenance  alternatives  would 
include  PCR  adjustments  only,  blade  resequence  with  PCR  adjustments,  and  blade  tab 
combined  with  PCR  adjustments.  This  feature  was  designed  but  is  not  yet  incorporated. 
An  additional  capability  that  could  be  added  is  to  provide  feedback  if  an  adjustment  was 
entered  incorrectly  (i.e.,  if  the  vibration  response  of  the  aircraft  was  different  or  opposite 
from  that  expected  based  on  the  maintenance  that  was  indicated  to  the  system  as 
completed).  This  feature  would  require  that  MCDS  keep  track  of  requested  versus  actual 
maintenance  performed. 

•  Dampers  -  Main  rotor  dampers  can  have  a  significant  effect  on  low  frequency  vibration 
comfort  levels.  Identification  of  a  misbehaving  main  rotor  damper  is  possible.  However, 
no  field  procedures  exist  for  the  UH-60A.  MCDS  detects  a  possible  damper  fault  through 
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examination  of  roll  vibrations.  Diagnosis  of  a  particular  damper  would  require  further 
flight  test  development  work  to  be  added  to  MCDS.  However  the  basic  instrumentation  is 
on  MCDS. 

•  Tail  rotor  balance  -  This  is  currently  accomplished  both  in  the  field  and  at  Sikorsky 
through  use  of  a  strobe  (for  phase  information)  and  accelerometer  with  the  adjustment 
calculated  manually.  MCDS  lias  replaced  the  strobe  with  a  magnetic  contactor  and 
automatically  calculates  balance  adjustments.  These  adjustments  can  be  provided  as 
specific  calculated  bolt/washer  configurations  if  the  existing  configuration  is  maintained  by 
MCDS  (current  practice  requires  the  maintainer  to  carry  a  scale  to  _.e  aircraft  to  weigh  the 
various  bolt/washer  combinations). 


Four-per-Rev  (4P)  Vibrations 

The  proper  operation  of  vibration  absorbers  in  the  UH-60A  aircraft  is  paramount  for  any 
troubleshooting  concept.  Early  UH-60A  aircraft  were  delivered  with  three  mass  absorbers;  later 
aircraft  with  only  two.  The  capability  of  providing  a  comfortable,  acceptable  environment  is 
dependent  on  the  efficiency  of  those  absorbers,  particularly  the  forward  cabin  absorber.  Efficiency 
of  an  absorber  is  a  function  of  proper  tuning  (resonant  frequency)  and  damping  ratio  (in  this 
instance,  minimum  friction  in  all  bearing/bushing  locations).  Both  functions  are  identifiable  and 
controllable  using  currently  known  algorithms.  These  procedures  are  currently  included  in 
maintenance  manuals.  MCDS  monitors  vibrations  at  two  absorber  locations  but  calculates  an 
adjustment  for  the  nose  absorber  only.  Extension  of  MCDS  to  calculate  cabin  absorber  tuning 
adjustments  could  be  made  but  this  would  only  be  allowed  in  maintenance  mode.  This  procedure 
is  restricted  to  maintenance  test  pilots  because  the  vibration  data  must  be  acquired  at  a  series  of 
points  around  100%  Nr,  which  requires  flying  the  aircraft  without  automatic  engine  control. 

Engine  High  Speed  Shaft 

Engine  high  speed  shaft  vibration  can  be  reduced  through  maintenance  actions  initiated  when 
vibration  levels  exceed  a  predetermined  level.  Currently  this  is  done  after  ground  runs  using 
procedures  contained  in  field  manuals.  MCDS  monitors  vibrations  in  flight  at  both  engine  drive 
shafts  and  indicates  specification  exceedances  as  well  as  trending  problems.  Vibration  data  is 
taken  on  a  periodic  basis  (currently  once  every  10  minutes). 

Oil  Cooler 


The  oil  cooler,  like  the  drive  shaft,  is  monitored  by  exceedance  of  a  vibration  level.  This  is  also 
covered  in  the  maintenance  manual.  MCDS  monitors  vibrations  at  this  location  and  indicates 
specification  or  trending  exceedances. 

Tail  Rotor  Drive  Shaft  (TRDS)  Bearing  Temperature 

MCDS  monitors  the  bearing  temperature  (as  it  differs  from  ambient)  and  will  issue  a  pilot  caution  if 
the  difference  exceeds  some  predetermined  value.  Early  MCDS  plans  called  for  vibration 
monitoring  here  as  well.  However,  further  investigation  found  that  the  accelerometer  installation 
was  difficult  and  that  the  chosen  track  and  balance  instrument  was  incapable  of  the  type  of  data 
analysis  that  would  be  required. 
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TRDS  Disconnect  Detection 


Since  MCDS  has  a  permanently  mounted  tail  rotor  RPM  pickup  and  accelerometer,  MCDS  can 
check  to  be  sure  that  the  tail  rotor  drive  is  intact  There  have  been  incidents  on  the  UH-60  where 
early  confirmation  that  the  tail  rotor  drive  has  been  lost  could  allow  safe  autorotative  descent. 
MCDS  can  only  check  this  periodically  due  to  requirements  to  share  these  same  channels  for  other 
measurements;  however,  a  concept  demonstration  is  possible  and  a  production  system  could 
dedicate  hardware  resources  to  continuously  monitor  this. 

General  Vibration 

To  discover  and  capture  other  possible  vibration  problems  for  which  specifications  may  not  be 
available,  MCDS  periodically  acquires  asynchronous  spectra  in  the  0-500  Hz  range  to  help 
identify  the  onset  of  vibrations  or  vibration  detectable  problems  before  they  become  noticeable  to 
the  pilot  or  observer  These  spectra  are  compared  to  a  reference  spectra,  and  any  vibrations  that 
exceed  the  reference  are  displayed  as  frequency  and  amplitude  pairs. 

Stabilator  Input  Monitoring 

The  cunent  approach  to  electronic  flight  control  troubleshooting  involves  following  a  detailed  fault 
tree  which  must  be  interactively  traced  on  the  ground.  Sikorsky's  flight  control  troubleshooting 
experience  indicates  that  often  the  problems  which  trip  system  trouble  indicators  cannot  be 
duplicated  on  the  ground  and  only  after  much  effort  are  traced  to  intermittent  bad  inputs  from 
sensors  while  in  flight.  MCDS  can  monitor  the  dual  sensor  and  stick  position  inputs  to  the 
stabilator  system  as  well  as  the  various  stabilator  related  caution  panel  discretes.  A  change  of  state 
of  either  of  the  key  discrete  indicators  will  automatically  record  a  time  history  of  all  monitored 
aircraft  parameters  which  can  be  examined  by  the  maintainer  after  the  flight  There  is  a  potential 
that  this  post-flight  analysis  could  be  automated  through  use  of  expert  systems,  and  a  preliminary 
set  of  troubleshooting  rules  were  developed.  These  basically  involve  various  cross-checks 
between  parameters  that  indicate  inconsistencies  pointing  to  specific  sensors. 

2.2.  SYSTEM  FUNCTIONALITY 

This  section  describes  the  intended  functionality  of  the  MCDS  from  the  user’s  viewpoint  with 
some  description  of  what  MCDS  is  doing  in  the  background.  A  description  of  setup  and  operation 
of  the  system  is  covered  in  Reference  1. 

Architecture  Overview 

To  understand  the  discussion  of  operating  modes  and  the  flight  walk-through  below,  a  basic 
understanding  of  the  system  architecture  is  required.  This  section  introduces  the  main  system 
components  and  their  role  in  MCDS.  Section  3  covers  the  MCDS  design  in  more  detail. 

There  are  four  major  components  that  comprise  MCDS: 

•  Flight  Data  Recorder  (FDR)  serves  as  the  primary  interface  to  the  normal  aircraft  sensors 
(i.e.,  airspeed,  altitude,  attitude,  and  weight  on  wheels)  and  determines  aircraft  state  (or 
regime)  which  is  used  to  guide  the  automatic  data  acquisition  process. 

•  Maintenance  Computer  (MC)  controls  system  operation  and  carries  out  most  of  the  data 
acquisition,  monitoring  and  diagnostics.  It  consists  of  a  modified  vibration  analysis 
instrument  with  two  components  and  a  sensor  suite.  The  Control  and  Display  Unit 
(CADU)  executes  the  system  software  and  controls  data  acquisition  that  is  carried  out  by 
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the  Data  Acquisition  Unit  (DAU).  Sensors  include  accelerometers  for  vibration, 
contactors  for  rotor  timing  and  a  track  sensor  for  rotor  position. 

•  Cockpit  Display  (CD)  is  installed  in  the  center  console  and  provides  for  pilot  interaction. 

•  Ground  Processor  (GP)  is  used  to  support  both  systems  providing  software  maintenance, 
calibration,  and  data  download  and  display. 

Each  of  these  components  is  linked  via  serial  communications  lines,  the  primary  one  allowing  a 
continuous  dialog  between  the  MC  and  the  FDR. 

MCDS  Operating  Modes 

The  MCDS  operates  in  the  following  modes  which  are  selectable  via  the  top  level  menu  from  the 
CD: 

System  Initialization  -  This  mode  starts  with  powerup  and  ends  with  the  display  of  the  main  menu  . 
on  the  CD.  As  each  unit  detects  presence  of  power,  it  initializes  its  software,  completes  Built  In 
Test  (BIT)  and  waits  for  communication  to  begin.  The  FDR  completes  powerup  first  and 
automatically  enters  its  monitoring/recording  mode  waiting  for  MC  commands.  If  the  GP  is 
connected  to  the  FDR,  it  enters  GP  mode  and  responds  to  GP  commands  instead.  If  neither  the 
GP  nor  the  MC  is  connected  and  functional,  the  FDR  will  still  record  data  normally  and  complete 
the  stabilator  monitoring  function.  The  MC  initiates  communications  with  the  FDR  and  if 
unsuccessful  enters  a  backup  mode  whereby  regimes  and  other  control  information  can  be  entered 
from  the  CADU  screen.  Displays  intended  for  the  CD  are  also  echoed  on  the  CADU  in  the  FDR 
backup  mode.  If  initialization  is  successful,  clocks  are  synchronized  and  normal  MCDS 
monitoring  mode  is  entered.  If  there  is  no  display  on  the  CD,  the  user  may  manually  switch  to  the 
backup  CD  display  on  the  CADU.  Hence,  failure  of  any  single  component  does  not  totally  disable 
the  MCDS. 

Monitor  Mode  -  In  this  mode  the  MCDS  continuously  watches  the  incoming  data  in  order  to 
detect  faults.  Monitoring  falls  into  two  categories: 

•  Regime  dependent 

•  Periodic  (or  regime  independent) 

Re  jime-dependent  acquisition  is  only  performed  if  the  aircraft  is  flying  in  a  diagnostic  regime  as 
determined  by  the  FDR.  There  are  currently  six  regimes  of  diagnostic  interest,  and  priority  is 
given  to  data  acquisition  if  one  of  these  is  detected  by  the  FDR  For  periodic  monitoring,  the 
system  samples  data  at  close  to  the  given  interval  (i.e.,  once  per  minute  or  once  per  10  minutes), 
validates  it  and  performs  diagnostic  routines  appropriate  to  the  data.  For  both  regime-dependent 
and  periodic  acquisitions,  if  the  data  indicates  a  problem,  the  pilot  is  notified  as  appropriate  to  the 
problem  urgency  in  general  accordance  with  the  flight  manual.  The  pilot  may  also  request  a  time 
history  in  this  mode  for  any  reason.  Time  history  data  is  continuously  buffered  on  the  FDR.  A 
time  history  request  will  cause  the  FDR  to  record  selected  parameters  and  the  MC  to  sequentially 
record  vibration  spectra  for  selected  channels.  If  the  system  discontinues  monitoring  for  any 
reason,  this  will  be  indicated  on  the  CD.  Pending  problems  will  be  stored  and  available  upon  pilot 
or  maintainer  request. 

Silent  mode  -  Toggles  between  ON  and  OFF.  If  ON,  MCDS  holds  all  advisories  until  the  pilot 
requests  status.  Cautions  and  warnings  are  displayed  regardless  of  this  mode  setting. 
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Maintenance  Mode  -  In  this  mode  the  maintenance  test  pilot  will  use  the  system  to  acquire  flight 
data  in  given  regimes  for  fault  isolation  and  to  verify  that  faults  have  been  removed/corrected  and 
that  the  aircraft  is  ready  for  mission  flight.  This  mode  gives  the  maintenance  test  pilot  access  to 
diagnostic  measurements  and  prompts  him  through  diagnostic  regimes  with  automatic  regime 
verification/data  acquisition.  The  tolerances  for  regime  identification  are  tighter  for  maintenance 
mode  since  the  pilot  is  specifically  flying  to  gather  data  for  maintenance. 

Expert  Mode  -  This  mode  is  similar  to  the  normal  testing  modes  available  on  current  commercial 
track  and  balance  test  equipment  In  this  mode,  the  expert  has  full  access  to  all  system 
measurements  and  data  processing  programs  as  opposed  to  the  preplanned  flight  plans  in  the 
maintenance  or  monitor  mode.  It  would  normally  be  used  by  operators  thoroughly  familiar  with 
the  system  and  vibration  diagnostics  and  will  run  on  the  CADU. 

Utility  Mode  -  In  this  mode  the  system  allows  the  user  to  view  selected  data  trends,  change 
selected  system  parameters  and  unload  data  for  backup.  These  options  are  briefly  described  below: 

•  Unload  data  -  transfers  control  to  the  CADU  to  enable  selective  transfer  of  airborne 
gathered  data  to  a  backup  file  for  later  transfer  to  backup  media. 

•  Alter  track  or  vibration  specifications  -  transfers  control  to  the  CADU  to  allow  selection  of 
certain  specifications  or  parameters  from  a  menu  on  the  CADU  and,  showing  what  the  old 
value  was,  allow  a  new  value  to  be  entered.  This  new  value  will  be  used  in  the  execution 
of  the  software  affected. 

•  Alter  aircraft  configuration  -  transfers  control  to  the  CADU  to  allow  update  of  the 
configuration  of  certain  components  (i.e.,  hub  weights  and  blade  serial  numbers).  The 
data  structures  being  updated  here  are  not  currently  utilized  as  part  of  the  diagnostics,  and 
use  of  these  would  be  a  potential  future  enhancement. 

Typical  Scenario  of  Operation 

The  following  section  walks  the  reader  through  a  typical  flight  using  the  MCDS. 

(Section  3.6  -  Software  Development  contains  flowcharts  and  more  detailed  descriptions  of  the 
software  involved). 

After  powerup/ initialization  (assuming  all  components  are  operational)  a  screen  will  appear  listing 
problems  from  the  previous  flight.  Figure  1  shows  an  example  of  a  typical  initial  status  screen. 
The  choice  of  “MENU”  will  display  the  main  menu  as  described  above  and  as  shown  in  Figure  2. 
If  nothing  is  selected  and  the  aircraft  begins  flight  (as  described  below),  the  system  will  default  to 
monitor  mode. 

On  detection  of  rotor  runup  (30  to  98%Nr),  the  FDR  issues  a  STARTFLT  regime  code  indicating 
the  start  of  flight ,  the  system  enters  monitor  mode,  and  an  entry  is  made  to  the  flight  log  noting  the 
time.  Figure  3  shows  an  example  monitor  mode  screen. 

When  the  FDR  detects  that  the  rotor  has  reached  100%  Nr,  it  issues  the  FPG 100  regime  code  and 
MCDS  acquires  main  and  tail  rotor  vibration  data.  Once  MCDS  has  enough  data  (at  least  3  points), 
each  data  point  is  examined  in  various  ways: 

•  First,  it  checks  for  scatter  which  would  indicate  an  instrument  problem. 
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•  Next,  it  is  checked  against  the  historical  trend  and  ignored  if  it  hasn’t  changed 
significantly  from  the  previous  point  (unless  it  is  the  first  point  in  the  flight  which  is 
always  kept). 

•  If  it  is  different  but  tracking  along  the  trend,  it  is  checked  against  specifications  and  if  it  is 
over  spec  limits,  MCDS  will  notify  the  pilot  and  attempt  to  calculate  corrections. 

•  Corrections  would  include  PCR  and/or  balance  weight  adjustments  for  the  example  flat 
pitch  regime  as  shown  in  Figure  4. 

•  If  more  data  is  needed  to  correctly  calculate  adjustments  (i.e.,  additional  regimes),  MCDS 
will  add  these  to  the  requested  regime  list  and  suspend  diagnostics  on  this  problem.  This 
list  is  available  to  the  pilot  at  various  points  whereby  the  pilot  can  fly  these  on  return  from 
his  mission  to  avoid  a  special  diagnostics  flight. 

•  Its  slope  is  calculated  next  and  if  it  is  increasing,  a  linear  projection  is  made  to  estimate 
when  it  will  exceed  limits  (prognosis).  If  the  exceedance  is  expected  shortly,  MCDS  will 
also  advise  the  pilot. 

•  If  no  problem  is  indicated,  MCDS  will  save  the  data  point  in  the  historical  data  base 
(MCDS  keeps  up  to  30  previous  points  for  about  30  different  parameters)  or  trash  it  if  it  is 
essentially  the  same  as  the  last  sample. 

Other  regimes  (Hover,  80Kts,  120Kts,  145Kts,  Vh)  are  handled  similarly  as  they  are  recognized 
by  the  FDR.  MCDS  insures  data  quality  by  monitoring  for  regime  stability  during  data  acquisition. 

The  pilot  may  request  status  at  any  time.  Status  is  presented  in  order  of  problem  severity 
(warnings,  cautions,  advisories)  and  chronologically  within  a  category. 

The  pilot  may  request  a  time  history  record  at  any  time.  The  system  will  immediately  commence 
data  acquisition  simultaneously  on  both  FDR  (which  also  buffers  the  previous  5  seconds  of  data) 
and  MC  subsystems  and  will  request  confirmation  of  storage  when  the  acquisitions  are  complete  as 
shown  in  Figure  5. 

When  aircraft  shutdown  is  detected  (rotor  below  98%  and  engine  torques  near  zero),  the  system 
will  log  the  ending  time  and  bring  up  the  final  status  screen  as  shown  in  Figure  6.  Processing  of 
any  unprocessed  raw  data  or  incomplete  diagnoses  will  continue  until  power  is  lost.  The  FDR 
indicates  if  any  time  history  data  needs  to  be  downloaded  and  examined  or  if  memory  usage  is  over 
80%  full.  Download  and  display  of  the  data  is  done  using  the  GP.  Figures  7  and  8  show  example 
MC  spectrum  graph  and  FDR  time  history  printouts  respectively.  If  the  system  failed  during  flight 
or  the  pilot  shut  down  quickly,  queues  of  both  unprocessed  raw  data  and  uncompleted  diagnostics 
are  maintained  and  processing  of  these  will  continue  during  the  next  flight.  In  the  case  of  a  system 
failure  where  there  was  no  automatic  entry  of  flight  ending  time,  MCDS  will  prompt  for  manual 
entry  of  the  flight  ending  time  which  will  be  added  to  the  flight  log  file.  This  is  needed  to  properly 
calculate  data  trends  which  are  based  on  flight  hours. 
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Figure  5.  Time  history  complete  screen 
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Parameter  ID 

T  ime 

Reading 

Cond i tion 

BIT  results 

0.00 

00000000 

mcds 

Rotor  Speed  (Nr) 

0.25 

Passing  50% 

GAG  data 

Weight-on-Wheels  Detect 

0.25 

OFF 

AIRBORNE 

Manual  Slew 

0.25 

OFF 

Stabilator  Failed 

0.25 

OFF 

Stabilator  Up  Limit 

0.25 

OFF 

Stabilator  Down  Limit 

0.25 

OFF 

Flight  Path  Stab. 

0.25 

OFF 

Weight-on-Wheels  Detect 

80.25 

ON 

LANDED 

Airspeed  #1 

80.50 

regime  0 

ROC  ON 

Radar  Altitude 

80.50 

regime  0 

ROC  ON 

Airspeed  #1 

SI.  00 

regime  0 

ROC  OFF 

Radar  Altitude 

81.00 

regime  0 

ROC  OFF 

Yaw  Rate 

387.75 

-0.25  deg/sec 

before 

MC 

req 

Pitch  Rate  HI 

387.75 

-0.25  deg/sec 

before 

MC 

req 

Pitch  Rate  #2 

387.75 

-0.25  deg/sec 

before 

MC 

req 

Load  Factor  (Nz) 

387.75 

0.98  G 

before 

MC 

req 

Rotor  Speed  (Nr) 

387.75 

79.82  7. 

before 

MC 

req 

Engine  Torque  (Ql) 

387.75 

79.58  % 

before 

MC 

req 

Engine  Torque  (02) 

387.75 

80.20  % 

before 

MC 

req 

Barometric  Altitude 

387.75 

-909.73  ft 

before 

MC 

req 

Barometric  Rate  of  Climb 

387.75 

0.00  fpm 

before 

MC 

req 

Airspeed  #1 

387.75 

30.38  knots 

before 

MC 

req 

Long.  Stick  Position 

387.75 

44.71  % 

before 

MC 

req 

Lat.  Stick  Position 

387.75 

45.11  % 

before 

MC 

req 

Coll.  Stick  Position  #1 

387.75 

45.03  % 

before 

MC 

req 

Coll.  Stick  Position  #2 

387.75 

45.03  % 

before 

MC 

req 

Pedal  Position 

387.75 

44.61  % 

before 

MC 

req 

Radar  Altitude 

387.75 

2.74  ft 

before 

MC 

req 

Temp.  TRDS  Bearing 

387.75 

25.98  deg  C 

before 

MC 

req 

Stabilator  Actuator  POSN 

HI 

387.75 

56.25  % 

before 

MC 

req 

Stabilator  Actuator  POSN 

H2 

387.75 

30.28  % 

before 

MC 

req 

Lateral  Acceleration  HI 

387.75 

0 . 00  G 

before 

MC 

req 

Lateral  Acceleration  H2 

387.75 

0 . 00  G 

before 

MC 

req 

Temp.  Tail  Drive  Amb 

387.75 

24.00  deg  C 

before 

MC 

req 

Rol 1  Attitude 

387.75 

1.41  deg 

before 

MC 

req 

Stabilator  Position 

387.75 

-23.85  deg 

before 

MC 

req 

Weight-on-Wheels  Detect 

392.75 

ON 

LANDED 

Manual  Slew 

392.75 

OFF 

Stabilator  Failed 

392.75 

OFF 

Stabilator  Up  Limit 

392.75 

OFF 

Stabilator  Down  Limit 

392.75 

OFF 

Flight  Path  Stab. 

392 . 75 

OFF 

REGIME  CODE 

387.75 

regime  1 

before 

exc/req 

REGIME  CODE 

388.75 

regime  1 

before 

exc/req 

REGIME  CODE 

389.75 

regime  1 

before 

exc/req 

REGIME  CODE 

390.75 

regime  1 

before 

exc/req 

REGIME  CODE 

391.75 

regime  1 

be  f  ore 

exc/req 

REVERSAL 

387.75 

reversal  0 

before 

exc/req 

REVERSAL 

388.75 

reversal  0 

before 

exc/req 

REVERSAL 

389.75 

reversal  0 

before 

exc/req 

REVERSAL 

390.75 

reversal  0 

before 

exc/req 

REVERSAL 

391.75 

reversal  0 

before 

exc/req 

END  OF  FLIGHT 


3.  SYSTEM  DESIGN 


Since  the  MCDS  was  designed  primarily  as  a  demonstration  of  the  application  of  existing 
technologies  to  ti  e  goal  of  onboard  monitoring,  a  conscious  effort  was  made  to  minimize  the 
development  of  new  hardware  and  software  and  to  use  as  much  “off-the-shelf*  components  as 
possible.  The  following  paragraphs  briefly  outline  the  development  process. 

First,  competing  rotor  diagnostics  and  flight  data  recorder  systems  were  evaluated  and  one  of  each 
was  selected,  'Hiis  selection  process  is  described  in  detail  in  Reference  2  and  was  based  on 
application  of  qualitative  rating  criteria  to  the  various  systems  under  consideration.  The  rating 
criteria  that  were  used  to  select  the  chosen  configuration  included  the  following: 

•  Technological  Maturity 

•  Cost  of  New  Software 

•  System  Reliability 

•  Integration  Difficulty 

•  Availability  of  Hardware 

•  Subsystem  Capability 

•  High  Level  Diagnostic  Language 

•  Standard  Operating/Development  Environment 

•  Unique  Features 

Second,  a  plan  was  developed  to  modify  the  chosen  equipment  into  the  required  MCDS 
configuration.  After  several  technical  exchanges  and  an  in-depth  review  of  the  technical 
documentation  of  each  selected  system,  the  “surgical  process”  to  convert  both  systems  from 
manual  operation  to  automatic  background  monitoring  was  defined.  Since  the  existing  rotor  track 
and  balance  systems  are  designed  as  support  equipment,  they  require  manual  operation  to  select 
and  initiate  data  acquisition  and  analysis.  The  diagnostic  capabilities  are  also  limited  to  basic  track 
and  balance  calculations.  Modifications  to  the  track  and  balance  system  required  addition  of 
software  to  handle  the  other  types  of  problems  as  well  as  to  convert  from  manual  to  automatic  data 
acquisition. 

Existing  FDR’s  are  primarily  stand-alone  and  thus  operate  as  passive  recording  devices  only.  In 
order  to  fulfill  its  intended  role  in  MCDS,  the  FDR  modifications  involved  addition  of 
communications  interfaces  and  changes  to  the  time  history  function  already  available  in  the 
structural  usage  monitoring  configuration. 

Based  on  this  modification  plan,  a  top  level  structured  design  was  completed  which  is  documented 
in  Reference  2.  This  included  the  definition  of  appropriate  data  structures  needed,  design  of  top 
flow  and  control,  and  determination  of  which  modifications  could  best  be  implemented  by 
each  subcontractor. 

Meetings  were  held  with  the  subcontractors  to  define  detailed  interface  specifications.  Since 
Sikorsky  was  also  making  modifications  to  subcontractor’s  software,  there  were  three  primary 
interfaces  that  needed  to  be  defined: 

•  the  communications  between  the  MC  and  the  FDR 

•  module  interfaces  between  Sikorsky  applications  code  running  on  the  MC  and  the 
controlling  MC  executive  program 
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•  module  interfaces  between  Sikorsky  applications  code  running  on  the  FDR  and  the 
controlling  FDR  executive  program. 

The  final  step  required  negotiation  of  contracts  for  the  defined  subcontractor  modifications.  All 
equipment  and  subcontracted  modifications  of  this  equipment  used  in  this  program  were  purchased 
by  Sikorsky. 


3.1  MCDS  ARCHITECTURE 

MCDS  equipment  configuration  is  shown  schematically  in  Figure  9. 


The  MCDS  is  composed  of  two  major  subsystems,  the  MC  and  the  FDR.  There  is  also  a  GP 
which  supports  the  major  airborne  subsystems.  The  following  section  briefly  describes  each  major 
subsystem  and  how  the  subsystems  tie  together  to  form  the  MCDS  (details  of  the  components  of 
each  subsystem  follow  in  section  3.2): 

3.1.1.  Maintenance  Computer  Subsystem 

This  subsystem  acquires  all  vibration,  blade  track,  and  rotating  shaft  position  data.  The  MC  also 
acquires  certain  data  from  the  FDR.  The  unit  analyzes  the  data  according  to  resident  diagnostic 
programs  and  provides  temporary  storage  of  data.  The  MC  also  contains  the  executive  program 
which  controls  the  monitoring  and  diagnostic  processing  as  well  as  the  overall  user  interfaces.  The 
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MC  has  a  separate  control  unit  capable  of  setting  up  and  executing  certain  data  acquisition  and 
processing  functions. 

The  MC  is  capable  of  stand-alone  operation  using  the  control  unit  or  in  conjunction  with  the 
ground  processor.  The  control  unit  has  a  self-contained  battery  for  temporary  power  so  that  data 
can  be  permanently  stored  prior  to  system  shutdown. 

3.1.2.  Right  Data  Recorder  Subsystem 

This  subsystem  acquires  data  from  aircraft  state  sensors.  The  FDR  analyzes  the  data  in  order  to 
recognize  when  a  stabilized  regime  of  diagnostic  value  is  being  flown.  The  unit  provides  this 
information  to  the  MC  so  that  regime  dependant  data  acquisition  can  be  performed.  The  unit  drives 
the  CD  and  transmits  information  to  and  from  the  MC.  The  FDR,  either  upon  command  from  the 
MC  or  upon  detection  of  certain  parameter  value  changes,  stores  a  parameter  time  history. 

The  FDR  subsystem  is  capable  of  stand-alone  operation  as  a  usage  monitoring  device  and  in 
conjunction  with  the  GP.  The  FDR  has  battery-backed  memory  so  that  data  can  be  permanently 
stored.  The  case  that  contains  the  GP  can  also  supply  power  to  the  FDR  during  data  download 
operations  and  contains  specialized  hardware  to  speed  up  download  data  transfer.  The  system  has 
self-test  capability. 

The  CD  allows  the  entire  MCDS  to  communicate  with  the  pilot  or  maintainer.  The  CD  also  allows 
the  pilot  to  activate  certain  MCDS  functions. 

3.2.  AIRBORNE  SYSTEM  DESCRIPTION 

All  MCDS  components  are  used  in  the  airborne  configuration  with  the  exception  of  the  ground 
processor.  The  tasks  that  are  performed  by  each  subsystem  are  described  below. 

3.2.1.  Maintenance  Computer  Subsystem 

Vibration  Measurements  -  The  system  monitors  vibration  levels  for  14  locations  (up  to  4 
simultaneously).  All  the  vibration  data  is  evaluated  by  Fourier  analysis.  Vibration  measurements 
are  of  two  types:  synchronous  (contactor  related  orders  of  main  and  tail  rotor  such  as  IP  main 
rotor,  4P  main  rotor,  IP  tail  rotor,  etc.)  or  asynchronous  for  non-rotor  (non-contactor)  related 
frequencies. 

Track  Measurements  -  The  system  measures  blade  track  from  one  or  two  track  sensors  (two  track 
sensors  are  necessary  to  make  this  system  extensible  to  the  CH-47).  For  the  UH-60A  only  one 
track  sensor  is  used.  The  system  is  capable  of  taking  both  relative  and  absolute  flap  and  lead/lag 
track  measurements  for  as  many  as  seven  blades.  The  track  sensor  is  hard-mounted  on  the  aircraft. 

Timing  Measurement  -  The  purpose  of  this  measurement  is  to  allow  identification  of  individual 
blades  for  the  rotor  system  adjustments  and  to  provide  a  reference  for  synchronous  vibration 
analyses.  Two  magnetic  contactors  (one  for  the  main  rotor  and  one  for  the  tail  rotor)  are  used  as  a 
part  of  the  permanently  mounted  instrumentation. 

Data  Processing  -  The  MC  provides  signal  and  data  processing  for  directly  accessed  sensor  data  as 
well  as  information  acquired  from  the  FDR.  The  operating  system  is  real-time  and  multi-tasking. 

Communications  -  The  MC  will  control  the  entire  MCDS  during  ground  and  flight  operations. 
Communication  from  the  MC  is  provided  through  RS232  ports  to  the  FDR  and  to  the  GP  when  it 
is  connected. 
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The  MC  subsystem  is  a  modified  version  of  the  Rotor  Analysis  and  Diagnostics  System  - 
Advanced  Technology  (RADS-AT)  produced  by  Scientific  Atlanta  of  San  Diego,  CA.  It  is 
composed  of  several  components  as  described  below: 

Control  and  Display  Unit  (CADU)  -  This  is  a  hand-held  computer  based  on  the  68000 
microprocessor  with  access  to  2  megabytes  (MB)  of  battery  backed  memory  and  programs  stored 
in  read-only  memory.  It  contains  most  of  the  MCDS  diagnostic  and  executive  software  which  is 
written  in  a  specialized  interpretive  language  running  under  the  OS/9  operating  system.  The 
CADU  maintains  communications  with  the  FDR  and  through  it  with  the  CD.  It  can  be  used  as  a 
flight  engineer’s  station  to  monitor  the  internal  functioning  of  the  MCDS  system.  There  are  also 
removable  “Credit  Card”  memory  devices  which  are  used  for  supplemental  storage  and  data 
archival.  Figure  10  is  a  photo  of  the  CADU. 


Figure  10.  Control  and  display  unit. 


Data  Acquisition  Unit  (DAU)  -  This  is  also  a  68000  based  system  with  specialized  signal 
processing  hardware  which  interfaces  with  accelerometers,  contactors  and  the  track  sensors.  It 
acquires  and  processes  vibration  and  track  data  under  command  from  the  CADU  and  relays  this 
data  to  the  CADU  for  storage  and  analysis.  Figure  1 1  is  a  photo  of  the  DAU. 

Accelerometers  -  MCDS  uses  standard  100  milivolt/G  accelerometers. 

Track  Sensor  -  This  is  a  fixed  mounted  unit  that  converts  measured  blade  position  into  a  digital 
pulse  train  which  is  interpreted  by  the  DAU  and  processed  into  flap  and  lag  track  information. 
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Contactors  -  Standard  magnetic  contactors  are  used  for  acquiring  main  and  tail  rotor  timing  data. 


Figure  1 1.  Data  acquisition  unit. 


3.2.2.  Flight  Data  Recorder  Subsystem 

Data  Acquisition  and  Processing  -  The  FDR  provides  signal  conditioning  for  all  FDR  connected 
sensors.  The  FDR  acquires  data  from  these  sensors  and  processes  it  to  determine  aircraft  regime, 
builds  certain  parameter  and  regime  histograms,  buffers  it  for  capture  of  time  histories,  and  passes 
requested  parameter  values  to  the  MC.  Each  analog  channel  is  tested  on  powerup  and  is  tested 
periodically  during  operation.  Each  channel  also  has  a  differential  input  in  series  with  isolation 
resistors  to  prevent  degradation  of  ship  systems. 

Communications  -  The  FDR  maintains  communications  with  other  systems  through  serial  ports. 
Its  I/O  ports  are  used  as  follows: 


Mating  System  Type 

MC  RS232 

CD  RS232 

GP  RS422 


Role 

Responds  to  MC  requests  for  regimes  and  data 
Passes  MC  display  commands  and  CD  keystrokes 
Used  for  data  download,  calibration,  and  program 
maintenance 


The  FDR  subsystem  includes  a  modified  version  of  the  Structural  Usage  Monitor  (SUM) 
produced  by  Canadian  Marconi  of  Kanata,  Canada.  It  is  composed  of  several  components  as 
described  below. 
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Flight  Data  Recorder  -  The  FDR  uses  a  1750A  microprocessor  with  its  own  memory  and 
access  to  an  auxiliary  memory  unit  composed  of  battery-backed  memory  for  data  and 
program  storage.  It  is  programmed  in  ADA  and  runs  under  a  proprietary  operating  program. 
Figure  12  is  a  photo  of  the  FDR. 


Figure  12.  Flight  data  recorder. 


Cockpit  Display  -  This  is  a  Canadian  Marconi  self-contained  display  unit.  It  is  a  smart 
terminal,  microprocessor-controlled  (Intel  80186/8087)  system  with  256  Kbytes  EPROM,  16 
Kbytes  RAM,  and  8  Kbytes  EEPROM.  The  unit  has  been  qualified  for  MIL-E-5400  Class 
1A  environmental  conditions  and  is  currently  in  production.  The  unit  has  a  display  capacity 
of  20  lines  at  21  characters  per  line  which  will  be  sufficient  to  provide  MCDS  messages.  The 
CD  is  5.75  inches  wide,  6  inches  in  depth,  and  9.375  inches  long.  It  will  be  located  in  the 
pilot's  side,  lower  control  console  to  enable  visible,  convenient  and  accessible  operation  for 
the  MCDS  demonstration.  Figure  13  is  a  photo  of  the  CD. 
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Figure  13.  Cockpit  display. 


Ground  Processor  -  This  is  a  portable  GRID  386  IBM  PC  compatible  computer  with  a 
80386  processor  running  MS  DOS.  It  is  used  for  downloading  and  analysis  of  airborne 
acquired  data,  system  software  maintenance,  and  potentially  extended  diagnostics.  It  is 
interfaced  to  the  FDR  using  a  custom  board  which  converts  RS422  serial  signals  from  the 
FDR  to  bidirectional  parallel  signals  on  the  GRID  computer.  Figure  14  is  a  photo  of  the  GP 
in  its  case. 
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In  general,  each  component  of  the  system  performed  reasonably  well  as  configured  for  MCDS. 
Opportunities  for  performance  enhancement  are  described  below. 

Maintenance  Computer: 

•  Onboard  memory  is  limited  to  2MB  which  must  store  program  code,  raw  data  awaiting 
processing,  and  historical  data.  The  final  code  size  required  offload  of  code  to  PROM  and  Credit 
Card  Memory  which  creates  software  development  and  data  reliability  problems  respectively. 
Enhancements  would  involve  adding  memory  capacity  and/or  reducing  code  size  by  recoding  into  a 
more  efficient  language.  This  code  translation  could  result  in  general  speed  improvement  as  well, 
since  compiled  languages  are  generally  more  efficient  than  interpreters. 

•  The  requirement  to  maintain  background  processing  for  FDR  communications  and  DAU 
monitoring  slows  overall  system  operations.  This  could  be  minimized  by  tuning  DAU  monitoring 
periods  and  FDR  polling  rates  to  optimize  system  performance. 
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Flight  Data  Recorder: 


•  The  overhead  of  filtering  display  commands  through  the  communications  protocol 
slowed  down  the  CD  to  the  point  where  it  took  minutes  to  update  screens.  This  was  improved  to 
about  10  seconds  by  preloading  display  data  that  can  be  called  with  single  commands,  but  further 
display  efficiency  improvements  are  possible. 

•  FDR  memory  limitations  required  that  a  maximum  of  20  seconds  (5  prior  and  15  after), 
of  time  history  data  be  kept  when  a  pilot  requests  a  time  history  record.  Additional  memory  on  the 
FDR  would  allow  this  period  to  be  extended  to  60  seconds  (15  prior  and  45  after),  allowing  a  more 
complete  vibration  survey  to  be  done  simultaneously. 


3.3.  PARAMETER  LIST 

Sensor  requirements  for  the  MCDS  system  are  shown  in  Tables  2  and  3.  Table  2  describes  the 
sensor  requirements  for  the  FDR.  Table  3  describes  the  sensor  requirements  for  the  MC. 

In  addition  to  the  data  usage  requirements  described  below,  the  system  provides  the  following 
sensor  interface  functions: 

Sensor  Conditioning  -  The  MCDS  provides  sensor  excitation  and  conditioning  for  sensors 
that  are  not  part  of  the  normal  aircraft  suite. 

Data  Validation  -  The  MCDS  automatically  and  continuously  checks  all  incoming  data  from 
sensors  for  validity.  This  includes  checking  for  sensor  circuit  shorts,  sensor  circuit  opens, 
over-full  scale  (saturation),  gain  accuracy,  and  abnormal  quiescent  channels.  The  system 
flags  invalid  data  to  allow  potential  system  operation  with  partial  sensor  failures  in  a  degraded 
mode. 

Sensor  Calibration  and  Setup  -  The  system  is  self-calibrating.  System  calibrations  will 
consist  of  V-cals,  R-cals,  sensitivities  or  range  checks  (i.e.,  accelerometer  turnovers)  for 
proper  phasing. 

There  are  basically  three  categories  for  data  usage: 

Regime  Recognition  -  The  values  from  these  sensors  are  periodically  fed  to  the  regime 
recognition  software  which  outputs  a  regime  code  (currently  once  per  second). 

Vibration  and  Track  Measurements  -  These  are  monitored  during  flight,  compared  against 
specifications  and  trended  against  previous  history.  Exceedances  or  near  exceedances  are 
reported  and  additional  data  may  be  requested  to  allow  calculation  of  corrective  adjustments. 

Special  Diagnostic  Sensors  (temperature,  TRDS  RPM,  stabilator  inputs)  -  These  are 
processed  in  similar  manner  to  the  vibration  data  except  for  the  stabilator  inputs.  The  inputs 
to  the  stabilator  amplifiers  are  normally  used  to  calculate  and  adjust  instantaneous  stabilator 
position  by  the  aircraft  system.  These  inputs  are  buffered  along  with  remaining  aircraft  state 
data  (for  5  seconds).  MCDS  monitors  the  discretes  that  indicate  a  stabilator  problem  to  the 
Caution  Warning  Advisory  (CWA)  panel  and  captures  a  buffered  time  history  if  they  change 
state.  This  history  can  later  be  examined  to  determine  the  possible  cause  of  failure  (especially 
if  it  is  intermittent). 
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TABLE  2.  MCDS  FLIGHT  DATA  RECORDER  PARAMETER  LIST 
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TABLE  3.  MCDS  MAINTENANCE  COMPUTER  PARAMETER  LIST 


Item 

No. 

Parameter 

Sensor 

Type 

Primary 

Use 

Secondary 

Use 

1 

Copilot  Vertical  (A) 

Accelerometer 

1 P  Main  Rotor 

3P  &  4P  Main  Rotor 

2 

Pilot  Vertical  (B) 

Accelerometer 

1 P  Main  Rotor 

3P  &  4P  Main  Rotor 

3 

Copilot  Lateral 

Accelerometer 

IP  Main  Rotor 

Damper 

4 

Nose  Vertical 

Accelerometer 

4P  Main  Rotor 

3P  Main  Rotor 

5 

Cabin  Absorber  Frame  Vertical 

Accelerometer 

4P  Main  Rotor 

6 

Tail  Rotor  Gearbox 

Accelerometer 

IP  Tail  Rotor 

Pylon  Drive  Shaft 

7 

#1  Engine  Drive  Shaft 

Accelerometer 

1 /Shaft 

8 

#2  Engine  Drive  Shaft 

Accelerometer 

1 /Shaft 

9 

Oil  Cooler  Longitudinal 

Accelerometer 

1/Oil  Cooler 

10 

Copilot  Vertical  (A)  Backup 

Accelerometer 

1 P  Main  Rotor 

11 

Pilot  Vertical  (B)  Backup 

Accelerometer 

IP  Main  Rotor 

12 

Copilot  Lateral  Backup 

Accelerometer 

1 P  Main  Rotor 

13 

Nose  Vertical  Backup 

Accelerometer 

4P  Main  Rotor 

14 

Spare 

Accelerometer 

15 

Main  Rotor  Track 

Optical  Track 

Track 

16 

Main  Rotor  Timing 

Mag.  Contactor 

Reference 

17 

Tail  Rotor  Timing 

Mao.  Contactor 

Reference 

3.4.  INSTALLATION  HARDWARE 

A  complete  set  of  brackets  and  fixtures  were  designed  and  fabricated  to  allow  the  MCDS  to  be 
installed  in  the  test  helicopter.  They  included  items  such  as  accelerometer  mounting  brackets, 
equipment  mounts,  connector  patch  panel,  etc.  Wherever  possible,  existing  designs  were  used  or 
slightly  modified.  However,  two  installations  required  some  development  Both  of  these  were 
fabricated  and  flight  tested  on  UH-60  aircraft  at  Sikorsky  and  worked  satisfactorily.  These 
included: 

Track  Sensor  Enclosure  -  This  was  needed  to  protect  the  sensor  from  the  weather  during  the 
planned  extended  flight  evaluation  and  due  to  changing  the  mounting  location  to  improve  viewing 
angle  and  prevent  blockage  of  the  E-Bay  vent  Figure  15  is  a  photograph  of  the  completed  unit. 

Tail  Rotor  Contactor  -  This  was  needed  to  provide  a  reliable  permanent  location  (a  tail  rotor 
contactor  is  not  normally  used  on  the  UH-60A  -  tail  balance  timing  data  is  generally  acquired  with 
a  strobe).  The  bracket  accepts  both  magnetic  and  optical  sensors  and  both  were  tested  on  aircraft. 

All  installation  locations  are  summarized  in  Figure  16  and  some  significant  points  are  described 
below: 

The  cockpit  display  is  located  in  the  center  console  between  pilot  and  copilot  to  allow  viewing 
and  interaction  with  the  system.  The  display  is  sunlight  readable  and  all  interaction  is 
through  ten  “soft-function”  keys,  some  of  which  change  meaning  based  on  the  active  screen. 
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The  CADU  enclosure  is  located  aft  of  the  center  console  and  allows  the  CADU  to  be  stowed 
(and  protected)  when  it  is  not  used  or  removed  for  use  as  a  flight  engineer  station. 

The  remote  panel  was  designed  for  the  SUM  program  and  a  copy  was  fabricated  for  MCDS. 
It  is  located  in  the  center  console  and  allows  connection  of  the  GP  to  the  FDR  for  data 
download,  software  update  or  calibration.  FDR  BIT  and  status  indicators  are  remotely 
displayed  here  also  (in  case  the  FDR  is  mounted  in  an  inaccessible  location). 


The  estimated  installed  weight  of  the  MCDS  is  98  lbs.,  of  which  the  major  components  include: 
FDR  16  lbs.,  DAU  10.8  lbs.,  CADU  4.4  lbs.,  CD  10  lbs.,  track  sensor  4.4  lbs.  and  wiring 
harness  22  lbs.  The  remaining  30  lbs  includes  other  sensors  and  mounting  hardware. 

3.5.  AIRCRAFT  WIRING 

Since  a  wiring  diagram  must  be  customized  to  the  specific  tail  number  aircraft  that  it  will  be  used 
on,  programmatic  changes  resulted  in  several  versions  of  wiring  harness  designs  before  the  final 
version  was  fabricated: 

•  For  the  original  planned  Ft.  Rucker  aircraft  with  a  Sundstrand  interim  tape  recorder  as  a 
replacement  (i.e.,  the  Sundstrand  was  planned  to  be  removed  during  the  testing). 
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Figure  16.  MCDS  aircraft  installation  location  diagram. 


•  For  the  original  planned  Ft  Rucker  aircraft  with  a  Sundstrand  interim  tape  recorder  as  a 
tap-in  (permission  was  not  secured  to  remove  the  Sundstrand  unit  and  hence  both 
recorders  needed  access  to  some  overlapping  sensors). 

•  For  the  Army  bailed  aircraft  to  be  used  at  Sikorsky’s  WPB  facility  with  no  other  FDR  and 
equipment  relocated  to  cabin  instead  of  aft  of  the  fuel  cell.  This  version  was  fabricated. 

Figure  17  depicts  the  top  level  harness  design  which  is  detailed  on  drawing  T7055-01 113.  The 
“Task  Number”  designations  match  to  related  installation  drawings  for  each  installed  item. 


Figure  17.  MCDS  top  level  schematic  diagram. 


3.6.  SOFTWARE  DEVELOPMENT 


This  section  documents  the  design  and  development  process  for  the  major  MODS  software 
components.  There  were  two  subcontractors  involved  in  both  hardware  and  software 
modifications  of  their  equipment  in  support  of  the  MODS  contract.  Their  efforts  were  considered 
part  of  the  cost  of  the  equipment  that  Sikorsky  purchased  and  are  so  noted.  Their  efforts  are 
described  here  for  reference  only. 

Regime  Recognition 

The  regime  recognition  function  was  developed  by  Sikorsky  under  a  previous  Navy  program  (see 
Reference  3)  and  was  slightly  modified  for  MCDS.  It  was  written  in  Ada  on  an  IBM  PC 
compatible  and  compiled  into  the  FDR  onboard  software  by  Canadian  Marconi.  The  FDR 
provides  the  current  value  of  all  regime  recognition  parameters  to  the  regime  recognition  application 
once  per  second.  The  module  examines  each  parameter  and  classifies  it  into  one  of  a  defined 
subset  of  levels  per  the  applicable  regime  threshold  table  (maintenance  or  monitor  mode  version). 
These  levels  are  then  mathematically  combined  to  a  coded  value  which  is  then  matched  (via  a 
second  table)  to  a  regime  code  which  uniquely  identifies  the  regime  to  the  rest  of  the  system.  Table 
4  summarizes  the  criteria  used  by  the  regime  recognition  algorithm  to  determine  which  regime  the 
aircraft  is  currently  within. 


TABLE  4.  MCDS  REGIME  RECOGNITION  SUMMARY 


MCMTORMOCE 


REOME 

CCCE 

AIRCRAFT  REGIME 

ROTOR 

SPEED 

EN3NE 

TOFTOUE 

AIRSPEED 

RATE  OF 
CLIMB 

ANGLE 

OF  BANK 

YAM 

RATE 

RADAR 

ALTITUDE 

CONDITION 

■SElSil 

ONCFF 

PERCENT 

mors 

CEGRSS 

DEG/SEC 

FEET 

1 

START  FLIGHT 

CN 

30/08 

10/142 

25/35 

N/A 

<  ♦/-  15  0 

< 

♦A 

10.0 

N/A 

2 

FLAT  PITCH 

100 

CN 

08/102 

10/142 

25/35 

N/A 

<  ♦/-  15.0 

< 

♦/- 

100 

N/A 

3 

HCVER 

100 

CFF 

08/102 

10/142 

25/35 

<  W-  500 

<  W-  15  0 

< 

♦A 

10.0 

10/1500 

4 

80  KIAS 

100 

OFF 

08/102 

10/142 

70/00 

<  500 

<  W-  15.0 

< 

♦A 

10.0 

N/A 

S 

120  KIAS 

100 

CFF 

08/102 

10/142 

1 10/135 

<  w-  500 

<  ♦/-  15.0 

< 

♦A 

10.0 

N/A 

6 

145  KIAS 

100 

CFF 

08/102 

10/142 

135/150 

<  ♦/-  500 

<  ♦/-  15  0 

< 

♦A 

too 

N/A 

7 

Vh 

100 

OFF 

08/102 

10/142 

150/200 

<  ♦/-  500 

<  W-  15.0 

< 

♦A 

100 

N/A 

8 

END  FLIGHT 

<* 

30/08 

0 

25/35 

N/A 

<  W-  15.0 

« 

♦A 

10.0 

N/A 

MAW7EWNCEM00E 


REGME 

NUMBER 

AIRCRAFT  R 

EGIME 

WCK3HT 

ON  WHEELS 

RCHDR 

SPEED 

ENGNE 

TORQUE 

AIRSPEEO 

RATE  OF 
CUMB 

ANGLE 

OF  BANK 

YAW 

RATE 

RADAR 

ALTITUDE 

CONDITION 

ONOFF 

mors 

|Bi 

FffT 

1 

START  FLIGHT 

04 

30/00 

10/142 

25/35 

N/A 

<  ♦/-  10  0 

<  ♦/•  5  0 

N/A 

2 

FLAT  PITCH 

100 

04 

00/101 

10/142 

25/35 

N/A 

<  ♦/-  10.0 

<  ♦/-  5.0 

N/A 

3 

HCVER 

100 

CFF 

00/101 

10/142 

25/35 

<  ♦/-  200 

<  ♦/•  10  0 

<  ♦/•  5  0 

10/1500 

4 

80  KIAS 

100 

CFF 

00/101 

10/142 

75/85 

<  ♦/-  200 

<  W-  10  0 

<  ♦/-  s  o 

N/A 

S 

120  KIAS 

100 

CFF 

00/101 

10/142 

1 15/195 

<  ♦/*  200 

<  ♦/-  too 

<  ♦/•  5.0 

N/A 

6 

145  KIAS 

100 

OFF 

00/101 

10/142 

140/150 

<  ♦/-  200 

<  ♦/.  10  0 

<  ♦/-  S  O 

N/A 

7 

Vh 

100 

OFF 

00/101 

10/142 

150/200 

«  ♦/•  200 

<  ♦/-  10  0 

<♦1-5  0 

N/A 

a 

END  FLIGHT 

CN 

30/00 

0 

25/35 

N/A 

<  ♦/-  10.0 

<  ♦/-  5  0 

N/A 

27 


Monitoring  Mode/S vstem  Executive 


This  function  is  composed  of  a  number  of  modules  coded  by  Sikorsky  in  a  Scientific  Atlanta 
proprietary  Diagnostic  Programming  Language  (DPL).  DPL  is  an  interpretive  language  which  was 
designed  to  allow  simple  access  to  the  data  base,  graphics  and  measurement  functions  of  the 
RADS-AT.  DPL  code  is  developed  on  a  SUN  workstation  using  a  development  environment 
which  simulates  the  display  screen  of  the  RADS-AT  CADU,  allowing  testing  of  screen  and  data 
base  related  functions.  The  DPL  code  is  then  partially  compiled  into  modules  which  run  on  the 
target  CADU.  Figure  18  shows  the  software  development  setup  including  the  SUN  workstation 
and  the  target  RADS-AT  system  where  the  code  is  tested.  Figure  19  illustrates  the  basic  flow  of 
monitor  mode.  The  measurement  data  processing  function  involves  taking  the  data  returned  by  the 
RADS-AT  DAU  (which  contains  much  more  information  than  MCDS  requires)  and  queuing  them 
for  the  data  filtering  process  which  extracts  the  pertinent  values.  These  are  then  stored  in  a  buffer 
which  holds  them  until  they  are  passed  to  problem  diagnosis  (described  below)  which  actually 
determines  what  is  to  be  done  based  on  the  data  value. 


Figure  18.  MCDS  maintenance  computer  software  development  environment. 
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Cockpit  Display  Drivers 

These  functions  are  responsible  for  maintaining  the  screens  and  handling  keystrokes  received  from 
the  CD.  They  were  coded  by  Sikorsky  in  DPL  to  send  line  by  line  screen  updates  which  were 
passed  through  the  FDR  to  the  CD  in  its  native  language.  This  approach  worked  well  during  early 
testing  (while  directly  driving  the  CD  from  the  SUN  workstation)  but  slowed  down  unacceptably 
when  MC/FDR  communications  link  was  finally  used.  This  problem  necessitated  conversion  to  a 
method  of  preloading  many  display  commands  to  be  called  using  the  CD  “macro”  facility. 

Records  of  the  screens  are  also  stored  on  the  CADU  data  base  for  log  purposes,  and  a  backup 
mode  allows  the  same  displays  to  be  viewed  on  the  CADU  in  a  slightly  different  format  (due  to 
display  shape  differences). 

Data  Screening  Algorithms 

These  modules  were  also  developed  in  DPL  by  Sikorsky.  Figure  20  depicts  a  model  flowchart 
from  which  all  specific  problem  diagnosis  scripts  are  derived.  The  screened  data  is  finally  stored  in 
the  vibration  history  file  by  vibration  parameter  number  classification  which  matches  the 
specifications  shown  in  Table  5. 


TABLE  5.  MCDS  VIBRATION  PARAMETER  SUMMARY 


VIB. 

PARM. 

NO. 

REGIME 

DESCRIPTION 

CHANNEL 

FREQ. 

GOAL 

(IPS) 

SPEC 

(IPS) 

LIMITS 

ONE 

(IPS) 

SLOPE 

SLOPE 

ROC 

1 

HOVER 

A  +  B 

1/M 

0.22 

0.10 

0.20 

0.50 

0.01 

0.10 

80  KIAS 

A  +  B 

1/M 

0.24 

0.10 

0.20 

0.50 

0.01 

0.10 

120  KIAS 

A  +  B 

1/M 

0.27 

0.10 

0.20 

0.50 

0.01 

0.10 

145  KIAS 

A  +  B 

1/M 

0.35 

0.10 

0.20 

0.50 

0.01 

0.10 

Vh 

A  +  B 

1/M 

0.48 

0.10 

0.20 

0.50 

0.01 

0.10 

FLAT  PITCH 

A  -  B 

1/M 

0.31 

0.10 

0.20 

0.50 

0.01 

0.10 

HOVER 

A  -  B 

1/M 

0.01 

0.10 

0.20 

0.50 

0.01 

0.10 

8 

80  KIAS 

A  -  B 

1/M 

0.02 

0.10 

0.20 

0.50 

0.01 

0.10 

9 

120  KIAS 

A  -  B 

1/M 

0.05 

0.10 

0.20 

0.50 

0.01 

0.10 

10 

145  KIAS 

A  -  B 

1/M 

0.02 

0.10 

0.20 

0.50 

0.01 

0.10 

1  1 

Vh 

A  -  B 

1/M 

0.04 

0.10 

0.25 

0.50 

0.01 

0.10 

1  2 

120  KIAS 

COCKPIT  LAT 

1/M 

0.21 

0.10 

0.20 

0.50 

0.01 

0.10 

1  3 

145  KIAS 

COCKPIT  LAT 

1/M 

0.23 

0.10 

0.20 

0.50 

0.01 

0.10 

14 

Vh 

COCKPIT  LAT 

1/M 

0.26 

0.10 

0.20 

0.50 

0.01 

0.10 

15 

145  KIAS 

A  +  B 

3/M 

N/A 

0.15 

0.20 

0.30 

0.01 

0.10 

1  6 

Vh 

A  +  B 

3/M 

N/A 

0.15 

0.20 

0.40 

0.01 

0.10 

1  9 

145  KIAS 

NOSE  VERT 

3/M 

N/A 

0.30 

0.40 

0.60 

0.01 

0.10 

20 

Vh 

NOSE  VERT 

3/M 

N/A 

0.30 

0.40 

0.80 

0  01 

0.10 

21 

145  KIAS 

A  +  B 

4/M 

0.57 

0.30 

0.40 

1.00 

0.01 

0.10 

22 

120  KIAS 

NOSE  VERT 

4/M 

0.40  1 

0.40 

0.60 

1.00 

0.01 

0.10 

23 

FLAT  PITCH 

TAIL 

1/T 

0.35 

0.10 

0.20 

1.50 

0.01 

0.10 

24 

PERIODIC 

#1  ENGINE 

350  Hz 

0.58  (Note  1) 

0.50 

1.30 

2.00 

0.01 

0.10 

25 

PERIODIC 

#2  ENGINE 

350  Hz 

0.58  (Note  1) 

0.50 

1.30 

2.00 

0.01 

0.10 

27 

PERIODIC 

OIL  COOLER 

70  Hz 

0.37  (Note  2) 

0.50 

1.00 

2.00 

0.01 

0.10 

28 

145  KIAS 

ABSORBER 

4/M 

0.24 

Note  1  - 

Varies  by  regime  from  0.75  to  4  at  352.5  Hz. 

Note  2  - 

Varies  from  0.5  to  3.0 

in  regime  "pilot  record" 

at  72  Hz. 

Note  3  - 

A  -  copilot  vertical  vibration. 

B  -  pilot  vertical  vibration. 

A+B  -  one  half  vector  sum  of  A  and  B. 

A-B  -  one  half  vector  difference  of  A  and  B. 
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Figure  20.  Model 


Determination  of  Maintenance  Actions 


These  modules  were  coded  in  DPL  by  Sikorsky  and  are  called  by  the  appropriate  problem 
diagnosis  script  to  generate  the  maintenance  action  recommendation.  The  basic  rotor  correction 
calculations  use  a  proprietary  Scientific  Atlanta  routine  which  optimizes  the  adjustments  to  data 
presented  via  predefined  sensitivity  factors  and  constraints.  Incorporation  of  these  Scientific 
Atlanta  modules  included  both  generation  of  new  (MCDS  specific)  DPL  code  by  Sikorsky  and 
Sikorsky  modifications  of  proprietary  Scientific  Atlanta  modules  to  allow  their  use  in  MODS.  The 
use  of  these  algorithms  (as  opposed  to  development  of  new  ones)  was  done  to  reduce  development 
time  and  maintain  compatibility  with  Expert  Mode. 

FDR  Operational  Program 

All  of  the  systems  and  applications  software  on  the  FDR  were  coded  by  Canadian  Marconi  under 
Sikorsky  subcontract  (except  the  regime  recognition  module  described  above).  Figure  21 
documents  the  basic  flow  of  parameter  processing  on  the  FDR.  Processing  is  data  type  dependant 
and  there  are  three  basic  types  as  indicated  in  the  FDR  parameter  table  (Table  2  in  section  3.3 ).  In 
summary,  type  1  and  2  discrete  parameters  are  recorded  into  a  time  history  only  when  they  change 
state  (where  type  2  parameters  are  related  to  problems  with  the  stabilator  system  and  cause  a  time 
history  sample  to  be  stored  as  well).  Type  3  parameters  are  quasi-static  and  their  values  are  stored 
when  they  change  by  more  than  a  defined  amount.  The  presence  of  a  time  history  which  was 
either  requested  by  the  MC  or  due  to  a  type  2  discrete  change  is  indicated  by  the  “exceedance” 
indicator  on  the  FDR  chassis  and  the  remote  panel.  A  subset  of  the  parameters  are  periodically  fed 
to  the  regime  recognition  algorithm. 

MC/FDR  Communications  Protocol 

This  consists  of  a  number  of  modules  coded  under  Sikorsky  subcontract  by  both  Scientific  Atlanta 
and  Canadian  Marconi  (both  under  Sikorsky  subcontract)  to  implement  the  MC/FDR 
communications  protocol.  Table  6  includes  a  summary  of  these  commands  and  their  use  in  MCDS. 
They  include  commands  to  synchronize  clocks,  request  regime  codes  and  parameter  values  from 
the  FDR,  control  the  time  history  storage  process,  and  relay  various  types  of  status  between  the 
two  systems. 


TABLE  6.  MCDS  MC/FDR  COMMUNICATIONS  PROTOCOL 
COMMAND  SUMMARY 


COMMAND 

DESCRIPTION  /  USE 

FDR  Time  Request 

FDR  Parameter  Value  Request 

Ftegime  Code  Request 

Regime  Table  Change  Request 

Time  History  Request 

FDR  Time  History  Status  Request 

FDR  Time  History  Store  Request 
Cockpit  Display  Test  Request 

Cockpit  Display  Command  Request 
Cockpit  Display  Key  Event  Ftequest 
FDR  Status  Request 

Requests  time  from  FDR  to  synchronize  clocks 

Requests  current  value  of  any  parameter  on  FDR 

Requests  latest  regime  code  as  determined  by  FDR 

Requests  FDR  to  change  to  Mission  or  Maintenance  mode 
Requests  FDR  to  immediately  capture  a  time  history 

Requests  status  of  last  time  history  requested 

Requests  FDR  to  store  or  delete  the  latest  time  history 

Ftequests  FDR  to  display  test  pattern  on  CD 

Requests  FDR  to  pass  command  data  to  CD 

Requests  latest  keypress  from  CD 

Ftequests  latest  FDR  BIT  status 
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Figure  21-  FDR  flowchart. 
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GP  Software 


The  primary  role  of  the  GP  is  to  support  the  FDR  and  to  download  and  display  data  stored  on  the 
FDR.  The  code  was  modified  from  the  SUM  version  by  Canadian  Marconi  under  Sikorsky 
subcontract.  Figure  22  outlines  the  main  menu  options  available  on  the  GP.  These  include 
software  update,  display  and  calibration  of  each  sensor  channel,  regime  recognition  table 
maintenance,  data  download/display,  and  checks  of  FDR  and  CD  functionality. 


FDR  Program  Load  and  Identification  Setup 
FDR  Sensor  Parameter  and  System  Constant  Load 
FDR  AMU  Right  Data  Download 
FDR  System  BIT 
FDR  Maintenance  Datadump 
FDR  Sensor  Parameter  Static  Test 
FDR  Sensor  Parameter  Calibration 
Data  Transfer  Between  Selected  Media 
FDR  Data  Download  Selection 
FDR  Right  Selection 
FDR  Right  Histogram  Display 
Regime  Recognition  Parameter  Histogram  Display 
Regime  Recognition  Histogram  Display 
Sensor  Validity  Check  Data  Display 
FDR  System  Constant  Update 
FDR  Sensor  Parameter  Data  Update 
Regime  Recognition  Threshold  Update  (Monitor) 
Regime  Recognition  Threshold  Update  (Maintenance) 
Regime  Recognition  Multi-Radix  Update 

Figure  22.  Ground  processor  main  menu. 


3.7.  SYSTEM  INTEGRATION 

Since  the  MCDS  is  tied  together  using  serial  communications  links,  the  major  task  in  design  of  the 
system  involved  defining  protocols  and  related  command  software.  A  communications  protocol 
for  use  between  FDR/CD  and  FDR/MC  was  designed  based  on  an  existing  protocol  used  between 
FDR  and  GP  in  the  previous  SUM  program.  This  was  designed  as  a  master/slave  scheme  with 
MC  acting  as  master  and  FDR  as  slave.  A  major  advantage  of  this  approach  is  that  the  complexity 
of  a  fully  bi-directional  protocol  was  avoided  and  that  modification  cost  (and  risk)  of  the  FDR 
software  was  minimized.  This  required  definition  of  interface  specifications  between  three 
companies.  Each  component  of  the  interface  was  separately  coded  and  tested  by  each 
subcontractor,  then  tested  together  at  a  low  level  (basic  message  passing/traffic  control  protocol)  at 
the  facility  of  one  of  the  subcontractors. 

As  a  final  step,  the  high  level  commands  were  tested  at  Sikorsky  during  system  integration  bench 
testing  (with  both  subcontractors  present  and  setup  to  correct  problems.)  This  co-location  approach 
to  system  integration  significantly  reduced  debug/repair  time  over  remote  efforts  at  separate 
locations.  Difficult-to-find  problems  included  those  which  involved  the  interface  between  the 
background  communications  monitoring  processes  (which  were  written  in  “C”)  and  the  DPL 
language  itself.  These  modules  were  initially  tested  by  calls  from  a  “C”  test  program  and  worked 
correctly  yet  would  not  function  when  called  from  within  the  DPL  interpreter  (where  they  are  called 
by  MCDS  diagnostic  software). 
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4.  TEST/DEMONSTRATION 


The  primary  focus  of  the  MCDS  testing  effort  was  to  verify  basic  system  operation  and  prepare  the 
MCDS  for  a  demonstration  of  these  capabilities  using  the  bench  test  setup.  The  detailed  test 
procedures  are  described  in  Reference  4.  The  testing  was  carried  out  over  a  5-month  period  from 
January  through  May  of  1990,  culminating  in  a  demonstration  of  the  system  for  an  Army  audience 
in  May.  This  testing  and  demonstration  was  completed  using  simulated  inputs  from  a  computer 
driven  data  simulator  which  provided  both  normal  and  fault  data  values  for  various  typical  flight 
conditions. 

4.1.  TEST  SETUP 

Figure  23  schematically  shows  the  MCDS  bench  test  setup.  Each  of  tne  major  testing  components 
in  this  diagram  is  briefly  described  below  and  depicted  photographically  in  Figure  24. 

Dynamic  Data  Simulator  (DPS') 

The  DDS  is  designed  to  directly  substitute  for  aircraft  installed  transducers  and  signal  sources  and 
consists  of  three  components:  the  host  computer  which  defines  20-30  channels  of  input  signal 
profiles,  the  digital/analog  hardware  which  converts  profile  definitions  to  0-1 0V  analog  signals, 
and  the  sensor  conversion  hardware  which  changes  the  0-10V  signals  to  simulated  sensor  signals. 
Prestored  flight  profiles  can  be  individually  played  out  or  strung  together  into  simulated  complete 
flights.  Note  that  certain  static  channels  are  simulated  with  signal  generators  rather  than  the  DDS 
and  that  rotor  RPM  is  varied  manually  to  indicate  start  and  end  of  flights  (STRTFLT  and  ENDFLT 
regimes). 

Interface  Panel 

The  interface  panel  simply  provides  an  exposed  interface  to  the  MCDS  bench  test  harness  for 
debug  purposes. 

Serial  Protocol  Analyzer 

The  analyzer  allows  continuous  monitoring/capture  of  serial  bus  traffic  between  either  the  MC/FDR 
or  FDR/CD  ports.  The  model  used  here  was  a  software  package  that  converts  an  IBM  PC 
compatible  to  handle  this  task. 

SUN  Workstation 


Besides  software  development  for  the  RADS-AT,  a  display  window  was  opened  as  a  terminal  to 
monitor  DAU  activity  during  requested  vibration  measurements. 

RADS-AT  Test  Set 

This  test  set  provides  simulated  (and  calibrated)  sensor  inputs  for  checkout  of  accelerometer,  track 
and  timing  inputs  to  the  DAU. 


35 


Figure  23.  MCDS  bench  test  block  diagram. 


4.2.  CHECKOUT  OF  DPS  OUTPUTS 

The  first  step  in  the  bench  test  sequence  was  to  verify  the  test  equipment  outputs,  the  bench  test 
harness,  and  the  interface  to  the  target  equipment.  This  was  completed  by  exhaustively  checking 
each  simulator  (or  signal  generator)  output  in  each  programmed  test  state  using  the  target  FDR  and 
MC.  The  FDR  testing  was  carried  out  using  the  static  display  and  calibration  mode  which  displays 
continuously  updated  parameter  readings  one  channel  at  a  time  on  the  GP.  The  MC  was  initially 
checked  out  for  calibration  purposes  against  it’s  test  set.  The  MC  inputs  were  then  checked  by 
using  Expert  Mode  measurements  during  each  simulator  test  state.  Any  discrepancies  that  were 
found  were  tracked  down  and  corrected  or  work-arounds  implemented.  Table  7  summarizes  the 
static  and  dynamic  inputs  to  the  MCDS  under  each  test  state. 

There  were  a  few  problems  which  were  never  resolved  and  were  demonstrated  as  work-arounds: 

•  Tracker  output  simulation  was  attempted  on  the  DDS  but  was  ultimately  unsuccessful. 

The  problem  was  never  successfully  duplicated  by  Scientific  Atlanta  at  their  facility.  The 
work-around  was  to  remove  track  acquisitions  from  the  demonstration  pending  a  separate 
checkout  of  the  track  data  processing  capability  from  the  RADS-AT  test  set. 
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Figure  24.  MCPS  bench  test  setup. 


•  Thermocouple  simulation  by  the  DDS  introduced  excessive  noise  and  was  thus  replaced 
by  actual  thermocouples  for  ambient  and  elevated  temperatures.  The  elevated  temperature 
was  introduced  via  a  hot  water  bath. 


4.3.  CHECKOUT  OF  COMMUNICATIONS  PROTOCOL  -  LOW  LEVEL 

Low  level  aspects  of  the  M C/FDR  communications  protocol  such  as  message  traffic,  flow  control 
and  communications  error  handling  were  tested  by  the  subcontractors  in  December  1989.  This 
was  done  at  Canadian  Marconi  using  a  serial  protocol  analyzer  to  monitor  traffic  and  simulate  fault 
conditions. 

4  4.  CHECKOUT  OF  COMMUNICATIONS  -  COMMAND  PROCESSING 

Once  a  command  has  passed  between  components,  the  receiving  unit  must  interpret  the  command 
and  carry  it  out.  Also,  the  sending  unit  must  properly  initiate  the  command  in  the  correct  format. 
These  functions  were  tested  at  Sikorsky  by  calling  individual  commands  from  DPL  interactive 
mode  while  monitoring  and  recording  message  traffic  using  the  “Breakout”  serial  protocol  analysis 
program  on  an  IBM  PC  compatible  as  described  in  4.1  above.  The  first  check  was  made  with  the 
MC  communicating  with  a  PC  running  an  emulation  of  the  FDR.  The  second  check  was  with  the 
actual  FDR. 
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TABLE  7.  MCDS  SIMULATOR  REGIME  CONTENT 
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MOTE.  CONSISTENT  PHASE  RELATIONSHIPS  MUST  BE  MAINTAINED  BETWEEN  CONTACTORS  AND  VIBRATION  SIGNALS,  IE: 

1)  TAIL  ROTOR  CONTACTOR  AND  TAIL  ACCELEROMETER  PHASES  MUST  BE  CONSISTENT  FROM  THE  BEGINNING  OF  THE  FIRST  CONDITION  TO  THE  END  OF  THE  LAST  CONDITION 

2)  MAM  ROTOR  CONTACTOR  AND  PILOT  VERT., COPILOT  VERT..  COPILOT  LAT.,  NOSE  VERT .  AND  ABSORBER  FRAME  ACCELEROMETER  PHASi  RELATIONSHIPS  MUST  ALSO  BE  MAINTAINED 

FOR  BOTH  THE  A  AND  16  HZ  FREQUENCIES.  THE  SAME  AS  1)  ABOVE 


4.5.  CHECKOUT  OF  SYSTEM  INTEGRATION 


Once  the  basic  communications  functions  had  been  verified,  the  next  step  was  to  test/debug  the 
Sikorsky  generated  application  programs  which  provide  the  overall  system  operation.  This  testing 
was  carried  out  in  the  following  order: 

•  CD  drivers  were  first  tested  by  direct  serial  interface  to  the  SUN  workstation,  then  by 
sending  individual  display  commands  from  interactive  DPL  and  finally  driven  by  the  full 
MCDS. 

•  Regime  recognition  was  tested  by  placing  the  FDR  in  time  history  mode  (which  also 
captures  regime  codes  and  the  intermediate  codes  which  can  be  parsed  to  verify  the  FDR 
interpreted  value  of  each  input  parameter)  with  each  of  the  available  simulated  regimes.  A 
final  check  was  done  to  venfy  that  the  regime  codes  were  correctly  received  by  the  MC. 
These  checks  were  carried  out  with  both  maintenance  and  monitor  mode  tables,  and  key 
parameters  were  varied  outside  their  normal  range  to  prove  that  the  tables  were  correctly 
interpreted. 

•  Regime  driven  data  acquisition  and  DAU  background  monitoring  was  checked  next.  This 
was  done  by  taking  the  MCDS  through  sample  flights  with  each  regime  and  monitoring 
activity  on  the  DAU  using  the  SUN  workstation.  After  a  series  of  successful  data 
acquisitions,  the  vibration  history  file  was  examined  to  verify  the  values  and  quantity  of 
data  points  stored.  In  addition,  the  function  which  monitors  DAU  progress  was  checked 
by  installation  of  diagnostic  code  that  continuously  displayed  the  DAU  status  on  a  CADU 
screen  and  comparing  this  with  the  actual  DAU  status  as  displayed  on  the  SUN 
workstation. 

•  Invalidation  of  data  should  occur  if  uie  regime  changes  during  an  acquisition.  This  was 
checked  by  changing  simulator  regimes  at  various  points  during  acquisitions.  This 
worked  well  except  that  a  problem  was  discovered  with  one  of  the  work-arounds.  Internal 
system  limitations  require  that  only  one  data  pipe  be  open  between  the  CADU  and  the 
DAU  at  a  given  moment.  Contention  for  this  pipe  forced  shortening  of  the  DAU 
background  monitoring  period  until  after  data  acquisition  was  underway  by  using  a  time¬ 
out  period  before  launching  the  monitoring  process.  This  left  a  brief  time  period  where  a 
change  in  regime  could  be  missed  by  the  system  and  the  data  incorrectly  associated  with 
the  wrong  regime.  This  was  fixed  by  verifying  that  the  regime  at  the  conclusion  of  data 
acquisition  is  the  same  as  when  the  measurement  was  initiated. 

•  TRDS  bearing  temperature  acquisition  was  checked,  placing  each  thermocouple  in  water 
and  viewing  the  GP  static  test  mode  display  for  both  channels. 

•  Time  history  mode  initiation  was  checked  both  by  request  from  the  CD  and  by  manually 
tripping  one  of  the  stabilator  discretes.  The  resulting  FDR  time  history  file  was 
downloaded  to  the  GP  and  examined  for  initiation  time  and  parameter  value  content.  The 
MC  vibration  time  history  spectra  was  also  checked.  CD  save  and  delete  options  were 
also  tested  in  a  similar  fashion. 

•  Transition  to  expert  mode  was  checked  by  requesting  a  time  history  be  taken  and  choosing 
expert  mode  from  the  CD  menu.  The  vibration  spectra  was  then  examined  using  expert 
mode  graphics  capabilities. 
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•  MCDS  is  able  to  recover  from  a  loss  of  MC/FDR  communications.  This  was  checked  by 
disconnecting  the  serial  cable  temporarily  and  monitoring  system  activity  on  the  CADU. 
The  system  noted  the  error  and  automatically  entered  backup  mode  (accepting  regime 
codes  from  the  backup  selection  menu)  and  took  data  accordingly.  When  the  cable  was 
replaced,  the  serial  traffic  resumed  and  the  system  was  successfully  restored  to  fully 
automatic  mode. 

4.6.  CHECKOUT  OF  FAULT  DETECTION  -  SIMULATED  INPUTS 

The  basic  method  of  checking  MCDS  abilities  to  diagnose  faults  involved  acquisition  of  data 
during  simulated  failure  regimes  and  verification  that  an  appropriate  CD  advisory  was  issued. 
Limitations  in  MCDS  bench  simulation  capabilities  prevented  all  implemented  functions  from 
being  verified  as  noted  below. 

IP  Vibration  Problems 

This  fault  is  simulated  by  overspec  vibrations  at  all  of  the  available  test  states  on  the  pilot  and 
copilot  accelerometer  channels.  This  verifies  the  ability  to  complete  tail  rotor  balance,  main  rotor 
balance,  and  high  speed  adjustments  to  PCR’s  and  blade  tab.  Flat  pitch  track,  high  speed  track  and 
hover  spread  algorithms  could  not  be  verified  since  track  simulation  was  not  available.  Track 
inputs  to  ground  and  high  speed  adjustments  are  routinely  conducted  by  Sikorsky  factory 
personnel  using  identical  equipment  and  algorithms  and  thus  should  function  properly  on  an 
aircraft.  Hover  spread  algorithms  will  require  verification  in  flight. 

Vibration  Absorber  Problems 

A  specification  exceedance  is  simulated  at  high  speed  regimes,  and  MCDS  will  detect  this  and  issue 
an  advisory. 

Damper  Problems 

Damper  problems  are  not  simulated  but  should  be  detected  by  MCDS. 

Engine  High  Speed  Shaft  Vibrations 

Engine  high  speed  shaft  vibrations  are  simulated  to  increase  from  0.85  to  4  ips  in  a  special  regime 
and  are  detected  by  MCDS  which  will  generate  an  advisory  (or  caution  if  the  level  is  over  3  ips), 
indicating  the  existence  of  the  problem. 

Tail  Rotor  Drive  Shaft  Bearing  Temperature 

This  bearing  temperature  is  simulated  with  a  hot  water  bath  and  MCDS  generates  a  caution  which 
displays  the  actual  temperatures. 

Oil  Cooler  Vibration 

The  oil  cooler  vibration  is  simulated  to  exceed  specifications  during  a  special  regime  and  MCDS 
will  generate  an  advisory. 
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General  Vibration 


Vibration  is  checked  by  manually  adjusting  the  reference  spectrum  for  a  set  of  frequencies  to  cause 
it  to  trip  and  generate  an  advisory.  This  will  require  further  adjustment  and  testing  under  actual 
flight  conditions. 

Tail  Rotor  Drive  Shaft  Disconnect 

This  is  simulated  through  a  special  regime  that  drops  RPM  from  20  to  16  Hz  and  causes  a 
coincident  drop  in  tail  rotor  vibration.  MCDS  will  generate  a  warning  message  with  advice  on  safe 
descent  procedures  from  the  flight  manual. 

Stabilator  Input  Monitoring 

Specific  problems  are  not  simulated  and  no  automated  diagnostic  code  is  available;  however,  the 
triggering  discretes  are  switch  controlled  and  MCDS  does  capture  the  correct  time  history  if  they 
are  manually  switched. 

4.7.  SUMMARY  OF  RESULTS/PROBLEMS 

A  bench  demo  was  shown  to  the  invited  Army  audience  in  May  1990  to  demonstrate  the  basic 
capabilities  of  the  MCDS.  The  following  is  an  outline  of  the  steps  that  were  executed  to  complete 
this  demo: 

Review  of  individual  bench  test  components  -  The  following  components  in  the  lab  were  described 
and  their  role  in  the  bench  demo  was  reviewed: 

•  Dynamic  data  simulator 

•  RADS-AT  subsystem  (it  was  noted  that  the  keyboard  attached  to  the  CADU  was  for 
convenience  only  and  is  not  a  required  part  of  the  system) 

•  FDR  subsystem 

•  Serial  protocol  analyzer 

•  SUN  workstation 

Demo  of  the  FDR  in  GP  mode  -  The  FDR  was  pre-booted  with  the  GP  connected  and  the  MC 
disconnected: 

•  A  BIT  check  of  the  FDR  was  requested  and  displayed. 

•  The  static  test  mode  was  shown  while  varying  rotor  RPM  (RPM  was  left  at  80%). 

•  The  static  test  mode  monitored  airspeed  as  the  simulator  was  changed  from  Vh  to  FPG100 
(160  Kts  to  30  Kts). 

•  The  CD  test  mode  was  requested  and  the  CD  function  keys  were  pressed  to  show  their 
effect  on  the  display. 
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•  The  regime  threshold  and  multiradix  tables  were  displayed  and  explained  (including 
differences  between  maintenance  and  monitor  mode). 

•  The  auxiliary  memory  pointer  was  reset  (to  clear  any  previously  stored  data  on  the  FDR). 

•  Power  was  removed  and  the  unit  repowered  with  GP  connected  switch  to  OFF. 

MCDS  was  then  demonstrated  as  a  system  by  walking  through  a  typical  flight  (initial  conditions 
included  the  simulator  in  the  STRTFLT  regime  with  Nr  at  80%,  serial  traffic  monitoring  was  on, 
the  DAU  was  monitored  by  the  SUN  workstation,  and  the  data  base  had  been  preloaded  with  at 
least  4  points  already  taken  at  each  test  state): 

•  The  harness  was  reconnected  to  the  CADU,  causing  communications  to  resume. 

•  The  main  menu  was  reviewed  and  utility  mode  was  demonstrated  (by  changing  a  vibration 
specification  and  restoring  it). 

•  MCDS  was  returned  to  monitor  mode  by  increasing  Nr  to  100%  which  changed  the 
regime  to  FPG100. 

•  The  system  took  2  data  points  while  the  data  acquisition  process  was  followed  on  the 
SUN  window  and  the  CADU  screen. 

•  The  DDS  was  switched  to  the  HOVER  regime  with  Nr  at  80%  (no  regime)  which  allowed 
the  system  to  analyze  the  data.  The  specification  exceedance  (0.305  vs.  0.2  ips  for  the 
main  rotor  hub)  on  the  first  point  caused  MCDS  to  generate  an  advisory  and  calculate  a 
hub  balance  correction.  The  second  point  was  deleted  as  it  was  nearly  the  same  as  the 
first. 

•  While  in  the  maintenance  mode  loop,  the  RECORD  button  was  pressed  to  capture  a  time 
history  (the  time  was  noted  and  the  Nr  was  varied  to  show  some  activity  in  the  FDR  time 
history). 

•  The  vibration  time  history  was  followed  on  the  SUN  and  when  the  CD  menu  came  up,  the 
KEEP  DATA  option  was  chosen. 

•  To  demonstrate  communications  fault  tolerance,  the  MC  harness  connector  was  removed, 
causing  the  CADU  to  note  the  FDR  error  and  display  the  REGIME  SELECTION  screen. 

•  The  MC  harness  was  reconnected,  the  RETRY  FDR  option  was  selected  to  resume  FDR 
communications,  and  the  DISPLAY  ON  CD  option  was  used  to  resume  CD 
communications. 

•  The  bearing  temperature  monitor  was  demonstrated  by  placing  the  thermocouple  in  a  cup 
of  hot  water  (near  100  *C).  A  caution  message  was  displayed  on  the  CD,  overwriting  the 
earlier  hub  balance  advisory. 

•  Maintenance  mode  was  chosen  and  explained.  The  HOVER  regime  was  entered  by 
increasing  Nr  to  100%  and  following  data  acquisition  on  the  SUN.  Upon  completion,  the 
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Vh  regime  was  entered  and  the  HOVER  state  dropped  from  the  regime  list  and  Vh  data 
was  taken. 

•  Maintenance  mode  was  exited  by  changing  Nr  to  80%  then  changing  the  DDS  regime  to 
ENDFLT. 

•  The  EXPERT  MODE  option  on  CD  was  selected  and  the  expert  mode  credit  card  memory 
was  inserted.  The  vibration  time  history  graph  was  displayed  (which  was  taken  earlier 
when  the  RECORD  button  was  pressed). 

To  examine  the  FDR  time  history,  the  FDR  needed  to  be  rebooted  in  GP  mode  and  the  data 
downloaded  and  displayed: 

•  The  FDR  was  powered  down  and  the  MC  was  disconnected. 

•  The  GP  connected  switch  was  changed  to  ON  and  the  FDR  repowered. 

•  A  FDR  BIT  check  was  completed  and  examined. 

•  The  data  download  option  was  chosen  and  the  data  was  downloaded. 

•  The  time  history  report  was  examined  and  matched  the  parameter  values  at  the  time  it  was 
taken. 

In  summary,  the  MCDS  demonstration  showed  that  the  basic  system  is  operational,  can  take  and 
analyze  the  data  based  on  flight  regime,  and  can  display  the  results  to  the  pilot  and  maintainer.  In 
preparation  for  further  testing,  the  diagnostic  capabilities  should  be  more  thoroughly  checked  and 
some  modifications  need  to  be  made  to  speed  up  CD  screen  updates  and  data  acquisition. 
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5.  AssEss-Nffim: 


The  following  ideas  are  offered  as  potential  extensions  to  the  MCDS  research  efforts. 

5.1.  FLIGHT  TEST  NEEDED  TO  EVALUATE/DEBUG  DIAGNOSTIC  ALGORITHMS 

The  use  of  simulated  fault  and  regime  data  during  the  bench  testing  showed  that  the  basic  system 
can  work.  However,  true  verification  of  the  diagnostic  algorithms  must  be  done  through  flight 
testing  on  a  real  aircraft.  Due  to  the  limitations  with  simulating  various  track  patterns,  some 
algorithms  (which  use  blade  track)  cannot  be  properly  checked.  In  addition,  the  variation  in  real 
aircraft  vibration  levels  during  various  flight  conditions  are  not  precisely  known,  and  thus  the 
trending  and  prognostic  functions  may  need  some  refinement  based  on  flight  experience.  Monitor 
mode  flow  should  also  be  verified  during  real  flight  (especially  the  effects  of  regime  stability  or 
lack  thereof)  to  verify  that  enough  data  will  be  acquired  using  the  opportunistic  sampling  scheme. 
Communications  and  data  acquisition  need  to  be  checked  in  real  aircraft  noise  environment  (which 
may  or  may  not  be  worse  than  the  lab  environment). 

5.2.  POTENTIAL  PRODUCTION  CONFIGURATION  AND  DEVELOPMENT  ROUTE 

Since  MCDS  was  designed  as  a  concept  demonstration  using  “off-the-shelf’  components,  a 
production  implementation  would  be  significantly  different.  This  section  describes  some  ideas  of 
how  a  production  version  could  be  developed  and  produced. 

Assuming  that  the  Army  continues  with  plans  to  install  digital  FDR’s  in  the  fleet,  to  reduce  system 
weight  and  size,  the  vibration  functions  should  be  reduced  to  a  boardset  that  could  end  up  in  the 
flight  data  recorder  using  some  of  the  spare  capacity  planned  for  maintenance  purposes.  The 
regime  recognition  function  could  either  be  imbedded  into  the  FDR  software  or  the  necessary 
parameters  passed  from  the  FDR  to  this  boardset  where  the  regime  determination  would  have  to  be 
done.  This  would  entail  a  hardware  development  and  qualification  process  and  recoding  the 
diagnostic  and  measurement  software  to  a  faster  compiled  language  suitable  for  airborne 
deployment.  CD  functions  should  be  reimplemented  onto  an  existing  onboard  display  subsystem 
(if  available^or  a  special  simple  controller  could  be  added  to  provide  minimal  onboard  control  and 
pilot  interaction  (a  full  CD  is  really  not  justified  for  this  application  alone). 

5.3.  USE  OF  MCDS  AS  A  DIAGNOSTIC  TEST  BED 

Prior  to  decisions  on  productionizing  MCDS  or  a  similar  system,  further  research  is  needed  to 
explore  other  diagnostic  technologies  and  concepts  to  synthesize  the  optimum  mix  of  mechanical 
diagnostics  to  be  added  to  each  aircraft  type  and  to  develop  the  necessary  background  data  to 
justify  the  cost  and  weight  penalties  of  onboard  diagnostics. 

Key  to  this  justification  would  be  the  definition  and  evaluation  of  several  Measures  Of 
Effectiveness  (MOE)  for  an  integrated  diagnostics  system.  These  might  include:  (a)  incremental 
improvements  in  the  accuracy  of  fault  detection  and  fault  isolation  (including  intermittent  failures) 
demonstrated  by  an  integrated  diagnostics  system  compared  to  the  current  system,  (b)  reductions  in 
training  time  and  costs,  (c)  savings  in  projected  spares,  (d)  offloading  of  test/support  equipment, 
and  (e)  improved  availability  of  helicopters.  Evaluation  of  these  MOE’s  should  continue  into  a 
field  evaluation  phase  where  the  integrated  diagnostics  system  could  be  tested  under  realistic 
conditions. 

The  MODS  is  designed  with  an  open  architecture,  has  the  basics  of  monitoring  and  data  handling 
in  it’s  current  configuration,  and  thus  could  be  used  as  a  flying  testbed  of  new  diagnostic 
technologies.  This  would  be  done  by  expansion  of  the  existing  MODS  FDR  chassis  to  add 
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additional  hardware  functionality.  There  are  additional  serial  ports  currently  available  for 
communications  from  these  new  functions  to  the  rest  of  the  MCDS.  The  primary  effort  would  be 
to  repackage  the  new  hardware  to  fit  inside  the  FDR  (or  simply  connected  to  the  FDR  harness)  and 
to  integrate  the  software  functions.  The  diagnostic  processing  could  be  handled  by  the  MC  (where 
the  communications  protocol  already  has  a  generic  information  passing  command  which  could  be 
reconfigured  to  other  data  types).  A  possible  expanded  architecture  is  summarized  in  Figure  25. 


Figure  25.  MCDS  expanded  architecture. 


Some  potentially  interesting  technologies  include: 

Electrostatic  Engine  Monitoring  System  (EEMS),  which  monitors  the  jet  engine  exhaust  for 
evidence  of  wear  degradation  or  damage. 

Inductive  Debris  Monitoring  (IDM),  which  is  a  potential  substitute  for  chip  detectors  that 
monitors  ferrous  and  nonferrous  debris  passing  through  the  oil  path. 

High  frequency  vibration  diagnostics,  which  typically  look  at  internally  induced  vibration 
signatures  of  mechanical  systems  such  as  the  gearbox  to  monitor  changes  that  might  indicate 
developing  problems. 

Structural  usage  monitoring  uses  regime  statistics  to  monitor  the  actual  usage  of  the  aircraft 
with  the  potential  to  eventually  affect  component  retirement  times.  This  would  primarily 
consist  of  FDR  software  changes  to  add  these  functions  back  in  (since  the  MCDS  FDR  was 
derived  from  a  usage  monitor). 

Interface  to  a  portable  maintenance  computer  to  allow  more  detailed  data  analysis,  logistics 
system  interface,  maintenance  procedure  prompting,  and  interaction  between  maintenance 
actions  and  airborne  diagnostics. 
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6.  CONCLUSIONS 


The  MCDS  program  has  met  its  basic  objective  of  demonstrating  a  mechanical  diagnostic  system, 
to  be  located  onboard,  which  calculates  IP  rotor  smoothing  adjustments  and  demonstrates  general 
vibration  and  flight  control  troubleshooting  concepts.  The  following  features  contribute  to  its 
utility  in  meeting  mission  goals: 

•  The  system  can  be  operated  to  gather  data  with  minimal  pilot  intervention,  thus  having 
little  impact  on  pilot  workload. 

•  It  provides  the  pilot  with  status  information  when  desired  and  the  ability  to  capture  data 
helpful  in  diagnosing  intermittent  problems. 

•  Since  most  of  the  vibration  data  gathering  is  accomplished  during  mission  flights,  there 
would  be  a  reduction  in  the  requirement  for  dedicated  maintenance  flights  to  tune  the 
aircraft  (potentially  zero  if  the  next  mission  flight  is  used  to  confirm  maintenance  success). 

•  The  maintainer  is  presented  with  specific  repair  instructions  which  minimize  his  required 
depth  of  understanding  of  the  vibration  dynamics  of  the  helicopter.  If  these  instructions 
are  followed,  the  MCDS  allows  the  aircraft  vibration  level  to  be  kept  at  an  optimum  level 
with  increased  component  MTBF  and  reduced  crew  fatigue. 

These  MCDS  benefits  can  reduce  aircraft  operating  costs  by  reducing  maintenance  time  and 
required  skill  levels  needed  to  maintain  mechanical  systems,  reduction  in  costly  maintenance  test 
flights,  extended  MTBF  of  many  electronic  components  by  lower  vibration,  and  reduction  in 
“retest  OK”  parts  in  the  supply  pipeline.  Aircraft  availability  would  correspondingly  increase  since 
the  time  spent  for  ground  maintenance  and  test  flights  directly  reduces  availability. 
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7.  RECOMMENDATIONS 


Based  on  the  results  of  this  effort  it  is  recommended  that: 

1.  MCDS  be  carried  through  flight  evaluation  (see  Reference  5).  This  would  include  flight 
testing  of  MCDS  using  inserted  faults  as  well  as  a  potential  longer  evaluation  period  where 
an  instrumented  aircraft  could  be  used  for  normal  mission  work  to  measure  the  usefulness 
of  the  MCDS. 

2.  The  system  be  expanded  to  include  other  capabilities  and  be  used  as  a  diagnostic  testbed  to 
evaluate  other  potential  diagnostic  technologies.  This  experience  would  be  used  to  define 
an  optimum  mechanical  diagnostic  system  within  fiscal  and  weight  constraints. 

3.  The  results  of  this  testing/; efinement  be  developed  into  a  specification  for  inclusion  into  an 
upgraded  UH-60  avionics  system  for  future  aircraft  models.  In  addition,  since  MCDS 
was  designed  with  enough  added  capacity  for  other  rotorcraft  models  (see  Reference  2),  it 
could  be  reconfigured  and  tested  on  other  models. 
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9. 


IP 

One-per-revolution  Frequency 

4P 

Four-per-revolution  Frequency 

BIT 

Built  In  Test 

CADU 

Control  And  Display  Unit 

CD 

Cockpit  Display 

CWA 

Caution  Warning  Advisory 

DAU 

Data  Acquisition  Unit 

DPL 

Diagnostic  Programming  Language 

EEMS 

Electrostatic  Engine  Monitoring  System 

FDR 

Flight  Data  Recorder 

GP 

Ground  Processor 

IDM 

Inductive  Debris  Monitoring 

MC 

Maintenance  Computer 

MCDS 

Mechanical  Component  Diagnostic  System 

MOE 

Measures  Of  Effectiveness 

PCR 

Pitch  Control  Rod 

PDR 

Preliminary  Design  Review 

RADS-AT 

Rotor  Analysis  and  Diagnostics  System  -  Advanced  Technology 

SUM 

Structural  Usage  Monitor 

TRDS 

Tail  Rotor  Drive  Shaft 
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